Agile Project Management A Primer

Agile Project Management A Primer

gile Project Management (also known as eXtreme or Radical Project Management) is an integrated set of tools and techniques for managing the new types of projects that have emerged in all organizations.

These projects are typified by: unstable requirements within evolving organizations; complex stakeholder inter-relationships; innovative business requirements; constrained deadlines, budgets and people; and tight focus on strategic alignment and added value realization. Traditional project management approaches (such as those in Prince 2 and the Project Management Institute) have failed to adapt to these projects and, as in other industries such as manufacturing and construction, new approaches to business and IT project management are demanded. While it is fashionable to deride traditional project management (typified by the PMBOK), these approaches worked well in the stable and engineered projects of the past. Simply, creative and dynamic project management must replace the overengineered and mechanistic project management of the past as projects (and organisations) become more creative, agile and dynamic. Agile Project Management is simply the management of creativity. Agile Project Management [APM] can be best understood through a comparison to traditional project management (TPM): TPM focuses on the development cycle of products and systems, APM focuses on the whole-of-life of products and systems (development, support and benefits realization). TPM treats quality, project risk and cost-benefit as plug-ins to scheduling, APM fully integrates quality, project risk and cost-benefit into the planning and management process. TPM treats team members as a resource that has costs and require constant tracking and review, APM treats team members as creative and motivated people who will work to achieve the projects success. TPM focuses downwards to the team and the managing the teams deliverables (cost, schedule, etc), APM focuses outwards and upwards towards the Sponsor, stakeholders and clients. TPM focuses on costs; APM focuses on benefits realization. TPM is expensive, report and forms-laden, slow and bureaucratic, APM is inexpensive, low-tech, rapid and open. There are many other distinctions, which include open participative planning (RAP sessions) and event/scenario planning. Most importantly, APM is based on open and collaborative partnerships between the project manager and the stakeholder/clients.

The two principle project management cultures

Project management models also reflect a specific culture and value system and the resultant behaviors have a significant impact on how project management is perceived and deployed within organizations. More importantly, the specific project management culture can have a major impact on the effectiveness of project management. Traditional project management, which is the most widely implemented and documented approach to project management in organizations has a set of values and behaviors that were borrowed from the construction and engineering industries that laid the foundation of all the key models such as scope, schedules and so on. These values and associated behaviors are: Closed Project management is undertaken by experts, who dont need input from users. The project manager owns the project the team, the budget, the scope and so on;

2007

Agile Project Management A Primer

Distrust Project team members and stakeholders need to be motivated, monitored and questioned at all times. If you dont monitor closely people will slack off. All estimates are padded and need to be haggled down; The true status of the project is to be positively presented. Not asking for help is seen as strength and telling management want they want to hear is quietly encouraged. Projects are reported as Green or Amber to avoid executive attention and possible punishment. Red status is reported at the last possible moment. Additional examples include inflating benefits and understating costs to ensure project gets approved; Not standing ground as professional, selling out the team and /or stakeholders by agreeing to unrealistic expectations (time, budget, scope, etc.), asking for help and assistance are seen as a sign of weakness as is admitting uncertainty and mistakes; The project is justified on the belief that great technology will automatically generate benefits. The more impressive the technology the most impressive the curriculum vitae. In addition, benefits analysis and realization belong to the users not the project manager. Dishonesty

Lack of courage

Technical fun

Agile project management (APM) evolved in leading business and IT areas as an alternative to the perceived bureaucracy and implied values and behaviors of Traditional project management. Agile project management values and behaviors are: Open Project management involves full participation and ownership by relevant stakeholders (including sponsors) and is facilitated by the project manager. The project manager owns the process not the project and its outputs and outcomes; Project team members, sponsors and stakeholders are professionals. They can be trusted to work hard and be committed to the project and the organization. If trusted, they will personally commit to work as hard as required not to betray the trust given to them. They will be honest with estimates if given the chance; All people impacted by or involved in the project have a right to be told the truth and inflating benefits and under estimating costs is not acceptable. The right to say I dont know the true estimates, can I have some time are seen as acceptable; Undertaking projects requires courage in many areas - telling the truth, asking for assistance, admitting uncertainty and mistakes are signs of strength, acting as a professional; Projects consume shareholders, citizens and corporate money and this requires a fiscal and ethical responsibility i.e. a duty of care to be shared by all team members, project manager, sponsor and stakeholders. Benefits realization is the responsibility of stakeholders but project managers must engage stakeholders and sponsor in ensuring that the benefits realization is planned and funded.

Trust

Honesty

Courage

Money

After 35 years of project management consulting, teaching and mentoring, we have come to understand is that, like children born in a specific culture that has been absorbed into the daily family rituals, education, media, laws and so on that surrounds the child, most people involved in projects, project management and project governance have become victims (or, at least, passive participants) of a culture its values and its behaviors.

2007

Agile Project Management A Primer

Agile Project Management: Overview
Agile project management is the management of creativity and innovation. It involves balancing two, often conflicting, concerns. The concerns are the technical aspects of the project (the content) and the managerial aspects of the project (the context). The technical aspects deal with the development of the specific outputs or deliverables of the project. The managerial aspects deal with the broader organization, financial, resource and time-frames of the project. Project management is different to technical management. It involves managing the context. All the research shows that projects that fail, fail in the context not the content.

MANAGERIAL
Stakeholders Related Projects Risks Returns Costs Schedules Priorities Estimates Resources Assumptions 10 - 20%

TECHNICAL
Policy Specifications Procedure Manual Design Scope Work Redesign Models Education Modules Objectives Test Plans Strategy Communication Strategy Quality Implementation Guides Legal Advice Public Relations Material

80 - 90%

Relative effort spent on each process

There are five basic processes in managing projects.

Prioritise, Steer Steer and and Prioritise, Review Projects Projects Review
Project Concept Project Business Case

Project Project Planning Planning

Project Project Feasibility Feasibility Assessment Assessment

Project Project Reporting Reporting

Project Project Tracking Tracking

Prioritize, Steer and Review Projects provides the executive governance - project sponsorship. Project Feasibility Assessment examines both the managerial and technical feasibility and risks. Project Planning develops the projects Business Case. Project Tracking monitors plans against actual status. Project Reporting reports the status of the project and Business Case to the Project Sponsor and stakeholders.

Project Planning (RAPs)

There are six steps in project planning which develops a Business Case and associated project schedule.
Planning is a creative problem These steps should be followed in sequence however some iteration or looping back will solving process. be required. For example, the initial project schedule may not meet the deadline so the Planning is working .. project development strategy may need to be changed and the risks, tasks and estimates working is not will be altered. Project planning should be conducted as an intensive team-based planning process involving key stakeholders and support groups such as Human Resources and Audit. RApid Planning (RAP) sessions are planning sessions where the stakeholders and team members undertake the project planning process following the six steps in sequence. You, the project manager, should act as the facilitator of the RAP.

2007

Agile Project Management A Primer

The RAP process (and associated tools) is the critical underpinning technique of Agile Project Management. Project planning produces the Business Case which is the key management contract between the information system development group and their clients. Any changes to the approved Business Case must be approved by the Project Sponsor, Owner or Steering Committee.
Project Concept Project Business Case

Determine Determine ProjectScope Scopeand and Project Objectives* Objectives*

DevelopProject Project Develop Schedule Schedule

SelectProject Project Select Development Development Strategy Strategy

Estimate Estimate Tasks/Project Tasks/Project

AnalyseProject Project Analyse Risks Risks

Develop Develop Project Task Project Task List List

* includes Stakeholder Analysis, Quality and Success Definition

Before you start planning, define success for the project

Agile project management adopts a whole-of-life perspective. Both the development and the support stages are planned and managed. This enables both the realization of benefits and the measurement of total costs development and support.

Development
Feasibility Analysis Design Build

Support

Benefits

Test

Ship

Costs

Benefits Realisation Review Post Implementation Review

The first and most important step in planning a project is to negotiate the expectations of success. Traditional project management defined success within the limited framework of the development stage of the project meets requirements, on time and in budget. Agile project management defines success from a development and support perspective.

2007

Agile Project Management A Primer

OFF ON

have a satisfied client group/s meet the project's objectives/requirements meet an agreed budget - resources, capital, equipment deliver the product on time add value for the organisation meet quality requirements have a sense of professional satisfaction for the team

OFF

ON

OFF

ON

OFF

ON

OFF

ON

OFF

ON

OFF

ON

Off - Success Factor is not relevant. It is measured however. On - Success Factor is relevant. Degree of relevance is indicated by position of slider.

Before planning, each critical stakeholder group defines success using the sliders. This negotiation should be done before any detailed planning.

Establish project objectives, scope, stakeholders

Scope and objectives
Scope is a statement of the area of responsibility of the project manager. Scope should state the boundary of the project and the objectives should state what to achieve and the specific responsibilities of the project manager.

PROJECT : IS IS NOT [Could be]

NOT RESOLVED

The objectives in scope are the responsibility of the project manager. The objectives outside scope are generally the responsibility of stakeholders. The unsure objectives must be resolved by the sponsor.

2007

Agile Project Management A Primer

Objectives are what the project is designed to achieve within the scope. Objectives should be specific and measurable and should identify business problems that are being solved. They should be stated with some benefit or end result in mind. The scope and objectives of the project can be combined by stating what objectives are in the scope of the project and what related objectives are outside the scope of the project. Developing a clear and precise statement of your projects scope and objectives is the most important step in planning a project.
A project without a clear statement of scope and objectives will fail and, indeed, has failed before it started.

This tool should be used during the planning session to identify the project's objectives and, by documenting related objectives outside the project, scope is defined as well. The results from completing this form can be stated as scope and objectives in the Business Case. Any un-resolved objectives should be forwarded to the Project Sponsor or Steering Committee for advice and resolution as soon as possible. The trick here is that while you, as the Project Manager, are responsible for the Is objectives, you must understand the related Is Not objectives and manage the relationship with the stakeholders and related projects that are undertaking the objectives outside scope.

Stakeholders and related projects

The project manager and team should identify any critical stakeholders and related projects. Stakeholders are people or groups outside the project manager's direct organizational control who must either provide a service or receive a service to or from the project. Critical stakeholders are generally those whose service is vital to the project's success. Related projects are a special form of stakeholder. A related project is a project that shares policy, process, technology, staffing, finance or staff impact with the project. Given that there can be many stakeholders and related projects for your project, you should partition your stakeholders and related projects into the following structure: Critical Essential Interested Party the stakeholder or related project can stop your project from achieving its objectives/outputs/outcomes showstopper - has veto rights the stakeholder or related project can delay your project from achieving it's objectives/outputs/outcomes - delayer - possible veto the stakeholder or related project has an interest in the project - no veto.

The Partnership Agreement is vital to the management of project stakeholders and related project managers.

Project or Partnership Agreements

The project manager should formally document any services required by key stakeholders and related project managers.

Project Title : ______________________ Stakeholder : _______________________

Services Required Timing Cost

Date : ___/___/___

Contingency

Person Responsible

List all the services, deliverables required by of from the stakeholder

Agree on effort or deadline requirement for the stakeholder

Determine if the stakeholder is going to charge you for the service

Negotiate who else can provide the service if the stakeholder is not available

Optional - agree which team member is responsible for the management of the relationship

2007

Agile Project Management A Primer

These agreements are designed to ensure that any key stakeholders or related project managers have been involved in the project planning process and that they are prepared to support the project. Key issues that should be agreed to in the agreements are: services involved; required timing of services; any costs incurred for the service; any contingency person.
Your project stakeholders can be your worst enemy or your best friends it depends upon how you communicate to and involve them in your project.

Stakeholder buy-in for your project is mandatory and the use of the RAP session which fully involves critical stakeholders in planning the project and developing the Business Case is a great way to get that buy-in.

A Primer on Benefits
The process of analyzing and estimating the benefits that the project is seeking to realize is driven by the projects objectives. As shown in the diagram, an objective produces an output which, in turn, leads to an outcome. The key to understanding benefits is that there are only three classes of benefits: I.R. - the objective leads to a direct increase of revenue; A.C. - the project leads to an avoidance of actual (i.e. staff reduction) or notional costs (i.e. there is an increase in productivity); I.S. - the project improves service to an internal or external client.

Objective Objective
An objective must state "what" is going to change in the status-quo.

Output Output
An output is the direct change in the status-quo as a result of the objective "delivering".

Outcome Outcome
An outcome is the indirect change in the status-quo as a result of the output being used to achieve a "secondary" change

Objective Objective

Output Output [Team] [Team] Primary Benefit Increase Revenue Avoid Costs Improve Service

Outcome Outcome [Stakeholder] [Stakeholder] Secondary Benefit

IncreaseRevenue Avoid Costs

Other Added Value Drivers

It is also reasonable to include factors such as Strategic Impact, Technology Impact and Organizational Impact as additional drivers to the financial analysis of R.O.I. (Return-On-Investment). The additional factors should be assessed using a common process and would be used along with Project Risk and Quality to assist in cross-project prioritization.
If your benefits are intangible, then the amount of executive support you will receive will also be intangible.

Define Quality
This tool is designed to assist you in gaining a more rigorous definition of the quality that your sponsor and critical stakeholders require for the product.

2007

Agile Project Management A Primer

Project : ATTRIBUTES CONFORMITY
Does the product have the desired data, function and procedures as required?

Date : ..../..../.... CRITICAL EXTERNAL GROUP OR STAKEHOLDER

USABILITY
Is the product easy to use, learn and understand from the end user's perspective?

EFFICIENCY
Does the application use the hardware, system software and other resources efficiently?

MAINTAINABILITY
Is the system easy to maintain and correct?

REUSABILITY
Does the system use code and data that is capable of being used by other systems?

FLEXIBILITY
Is the system easy to enhance in order to add or modify function and data?

RELIABILITY
Does the system operate without failure and with consistency?

PORTABILITY
Is the system easy to migrate to another hardware, software environment?

AUDITABILITY/SECURITY
Is the system secure from unauthorised access and is it auditable?

JOB IMPACT
Does the system provide acceptable working environment for direct users? M - MANDATORY N.A. - NOT APPLICABLE

Page ...... of .......

During the RAP session, you should ask each critical stakeholder to negotiate which of the quality attributes matters to them. Clearly, there is going to be major disagreements between the various stakeholders and you need to either, look for the majority view on each attribute or, alternatively, ask your Project Sponsor to decide unilaterally.

Project Development Strategy/Scenarios

The selection of the project development strategy is one of the most important decisions made during the project planning process. The project development strategy is different to the product development cycle which is the technical tasks involved in building products. The project development strategy determines the overall approach to the building of the product. There are five basic project development strategies: monolithic - where the total project requirements are developed in one sequence through the product development life cycle; sequential release - the project's requirements are broken into components or events and one component is developed sequentially through the product development cycle and placed into production. The next component is then developed through the product development cycle. Agile development is a highly-focused version of this strategy; concurrent release - the project's requirements are broken into components and each component is developed as separate releases concurrently. Each release follows the product development cycle; fast-track - the project's requirements are developed as quickly as possible using the minimum activities of the product development cycle. The "fast-tracked" production product is reviewed and improved using another fast- track project. This strategy is also called production prototyping or rapid development; and

2007

Agile Project Management A Primer

hybrid - a variation of concurrent release where different strategies are used for each component. For example, one release may be fast-tracked while another uses the monolithic.

Monolithic/Waterfall
Analyse Requirements Design Solution Build Implement Solution

Release/Version
Sequential
Analyse Overall Requirements Release 1 Release 2

Minimum Deliverable
Analyse Requirements Release 1 Design Release 1 Solution Build Release 1 Implement Release 1 Solution

Concurrent
Analyse Overall Requirements Release 1

Release 2

Analyse Requirements Release 2

Design Release 2 Solution

Build Release 2

Implement Release 2 Solution

Fast-track/Evolutionary
Fast-Track Version 1 Review & Reengineer Version 1 Fast-Track Version 2

Cut corners/ ASAP

Analyse Requirements Version 1 Design Version 1 Solution Build Version 1 Implement Version 1 Solution

The choice of strategy is dependent primarily on three factors: project risk; team size; and project duration (in time). Basically, the higher the risk, the longer the project and the bigger the team size, the more useful are the fasttrack and hybrid strategies. The monolithic strategy should only be used for projects that are low risk and less than 3 months in duration, in general. Events are an alternative concept to deliverables. An event is simply a significant point in a project. Scenarios are alternative paths through a particular strategy. Agile development is a highly aggressive form of Sequential Release.

2007

Agile Project Management A Primer

Complete risk assessment
Project risk management has two related processes. First, you assess the risks and second, you attempt to reduce and/or contain the high risks. Project risk assessment is a structured evaluation of risk factors that have been shown to affect the project's probability of success. The identification and elimination or reduction of high risk factors associated with the project is a key project planning process. The following process should be applied to risk assessment: using the form opposite each member of the team, stakeholders and project manager completes the risk factors questions from their own perspective; the members of the planning session then share their answers and discuss any major areas of difference in each person's risk factor assessment; after the discussion, if there is no consensus, a vote is taken on each risk factor with the majority vote being taken as the project risk factor - if the vote is tied then the worst case is selected; in the form on the next page, the overall risk is the sum of all risk factors though some factors may be given more weight than others. In other words, while the majority of the risks may be ranked as Medium because the requirements are assessed as unstable and the project has a fixed deadline, the overall ranking may be adjusted to High. Attempts should be taken during the planning session to try to minimize the impact of any high risk factors. This will involve negotiation with the Project Owner, Steering Committee and project manager. Other actions such as changing the project development strategy could also be required to reduce project risk. The second process of risk management is to analyse all high risk factors and develop a reduction or containment strategy. Any unresolved high risk factor should be documented as a Risk Memorandum with would include: the risk factor; the impact of the risk factor on the project; potential risk minimization strategies; and contingency actions should the risk factor "switch on" The Risk Memorandums are included in the Business Case. The high risk factors should be monitored closely during the product development cycle. The process of Risk Memorandums is the essential pro-active element of risk management This is the basic tool for assessing the risks of a project. It is completed during the RAP session. The risk assessment process should be undertaken democratically with all team members and critical stakeholders being involved.
When planning projects, it pays to be paranoid. In other words, plan for the worst and hope for the best.

Business versus Project Risk

The Business Risk of a project is the exposure (legal, financial, image, etc) that your company or organization faces should your project fail. The Project Risk is the factors that could cause your project to fail. Both sets of risk should be analyzed in conjunction with your Internal Audit or Risk Management gurus. Business Risk is clearly the concern of your Project Sponsor. A full model of Risk Management would include Benefits Realization Risk, Production Support Risk and Personal Risk.

Project Risk Impact

Project risk affects all aspects of projects however, the significant impacts are include: Estimation accuracy the higher the risk the more likely initial estimates are incorrect; Estimation range the higher the risk the larger the difference between best and worst case estimates Governance the higher the risk, the more attention and more often the meetings Sponsors and Steering Committees should provide to the project and project manager; and Contingency Plans the higher the project risk, the greater the need for a Contingency or Get out plan.

10

2007

Agile Project Management A Primer

Project : PRODUCT/SYSTEM RISKS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Overall system/service/product Logical data (include. files) I/O and enquiries or organisational impact Interfaces to other systems/services/products Functions and processes New business procedures/alterations Stability of requirements Performance requirements (including quality) Technology requirements Level of technical innovation LOW Simple Simple Simple Simple Simple None Stable Low Simple None LOW High Extensive Extensive 1-5 None 1 - 3 mths Flexible High Extensive Excellent LOW High Extensive High Low Full-time 1-2 LOW MEDIUM Average Average Average Average Average Some Average Medium Average Some MEDIUM Average Some Some 5 - 10 Some 3 - 6 mths Firm Average Average Average MEDIUM Medium Some Medium Medium Part-time 2-10 MEDIUM HIGH Complex Complex Complex Complex Complex Extensive Unstable High Complex Innovative HIGH Low None None over 10 Extensive Over 6 mths Fixed Low Some Poor HIGH Low None Low/None High Ad-hoc Over 10 HIGH

TEAM RISKS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Intrinsic team skills (general skills) Relevant skill level with application/product Project manager experience Project staffing level Use of contractors/part-time members Project development length Schedules/deadlines Priority of project for team Team experience with hardware/software or technology Project team physical/support environment

ENVIRONMENT/TARGET RISKS 1. 2. 3. 4. 5. 6. Level of client/user support Client experience with product/system Client Project Sponsor support Impact on client operations (new technology, policy,etc.) Client/business expert participation Key (Critical and Essential) stakeholders

OVERALL PROJECT RISK

Pro-active Risk Management revisited

All High Risk factors should be documented with a Risk Memorandum which states what the risk is and what mechanisms are available to manage the risk. The Risk Memo must be reviewed with the Project Sponsor. Risk Memos typically identify: what what what what is the risk factor? is its impact should it remain unresolved? can be done to manage or minimize the impact of the risk? is the fallback or Contingency Plan should the risk remain an issue?
NEVER start a project without an agreed fallback or Contingency Plan.

Develop task list/features list

The process of task listing should use the organization's product development framework (often called a methodology), if one exists. If Agile development approaches are being used, the relevant Compoments/Features identified during this process. The following process should be applied to developing task lists: using the product development cycle, the team extracts a "first-cut" list of the tasks contained in the product development cycle that are relevant to the project being planned. If there is no organisation standard P.D.C., then the team should brainstorm a "first-cut" task list using brain-storming, additional tasks not contained in the product development cycle but that are required for the project are listed the "first-cut" list should be broken into smaller tasks and reviewed by as many technical experts as possible.

11

2007

Agile Project Management A Primer

Determine Determine Test Test Plan Plan Evaluate Evaluate Package Package Review Review Vendors Vendors Convert Convert Test Test Data Data Obtain Obtain User User Group Group List List Contact Contact User User Sites Sites Select Select Site Site Visits Visits

The following tips are also suggested during the task listing process do not confuse task listing with scheduling - the sequence of execution of the tasks is considered during scheduling - task listing can be done as a free-form brainstorm; do not list tasks in phases that are beyond the phase or event currently about to be commenced. For example, in the project is about to commence the Product Requirements phase only list the tasks for that phase in detail; and check the task list with as many people as possible. A missed task is additional effort and could mean that the project will not meet the agreed Business Case and schedule. As the task list is the basis for detailed estimation, the process of task listing should be given as much care and effort as possible. All these processes are undertaken using micro-planning concepts that assume that planning and replanning are a continuous activity throughout the project development cycle. Change is inevitable in contemporary projects so re-planning is inevitable. Your projects Business Case must be maintained as it is a living document.

Undertake project sizing/estimates

Project estimation involves task-based estimates using Wide-band Delphi and phase-based estimation - which uses percentages across the various phases of the product development cycle. The following process should be applied to for Wide-band Delphi estimation: undertake an analysis of the projects Quality expectations (via the Quality Agreement) and a full Risk Assessment before you estimate; each member of the planning session estimates the initial phase task list using raw effort estimates i.e. one person in actual effort; estimates are derived for three ranges - Best Case where everything goes better than expected - Likely Case where things go as expected - Worst Case An estimate where things go worse than expected; undertaken by one person is WRONG. the members of the planning session then share their estimates and discuss The more people any major areas of difference in each estimate involved in after the discussion, if there is no consensus, any outriders are excluded and estimating, the more the remaining estimates in each range are averaged. A single point estimate is derived either by:
accurate estimate. the

Expected = Best Case + 4 x Likely Case + Worst Case/6 using an informal risk assessment for each task, low risk tasks are scheduled at the Best Case, medium risk tasks are scheduled at the Likely Case and high-risk tasks are scheduled at the Worst Case. Task-based estimation should be used only for the phase about to commence. Total project estimates are derived using phase percentages. For example, assuming Product Requirements is 25% of the total product development cycle then the total of the task-based estimates for Product Requirements are multiplied by 4 to derive a total product development effort. What is also important to remember is that the earlier the estimate is made, the more inaccurate it will be.

12

2007

Agile Project Management A Primer

Production Support Estimates
Based on our own research and that in the construction and engineering industries, you should allow a 1:1 ratio for product development and support. This is independent of the estimated product life-cycle.

Develop project schedule

There are three basic steps in developing a project schedule. The first is to develop a network or PERT diagram that shows the tasks and their dependencies. There are two common types of dependencies - Finish-to-Start where one task must finish before another can start - Startto-Start where one task can start after some time lag after another. These dependencies can either be a deliverable or a person.

Task A

Task B

Task D

This diagram indicates the sequence of undertaking tasks. The box indicates a task and the line indicates a dependency. In the diagram, Tasks B and C are dependent on Task A finishing and Task D is dependent on Tasks B and C finishing.

Task C

The second step is to factor in duration based on the estimated effort for one person to complete each task. Duration or elapsed time must take into account other non-project activities that the person must also handle during each day.
Critical Path
Task A 8 hours effort 2 days Task B 12 hours effort 3 days Task D 4 hours effort 1 day

The effort has been converted to elapsed or calendar days allowing for non-project tasks. The critical path is the longest path through the network.

Task C 8 hours effort 2 days

At this stage the Gantt chart can be produced and the initial critical path indicated. The critical path is the longest path in duration through the network. The final step is to allocate actual resources to your tasks and adjust the time-line. With Agile development, this process is more likely to be undertaken on a white-board.

Resource Assumptions
When you allocate people to your project and tasks, make sure that you clearly state what assumptions you are making i.e. skills, experience, attitude and so on. The more specific you are the more likely you can avoid substitution of less experienced people.

Stakeholder Communication
You should develop specific communication strategies for all your stakeholder groups. For Critical stakeholders, communication should be face-to-face; you must gain their sign-off for any change in the Business Case and they are fully involved in the RAP sessions. Essential stakeholders should be dealt with face-to-face if possible. Interested Parties should receive regular updates such as project status reports, newsletters and road shows.

13

2007

Agile Project Management A Primer

Project Business Case
The Business Case is the managerial contract between the information products development group and clients. It is developed during the planning session from the project concept or initiation documents. It should contain the following information: project scope and objectives; project stakeholders and related projects; project benefits; project costs (development and support); project development strategy; project risk assessment; risk memorandums; estimates; change management; schedules; any major assumptions and constraints; and quality agreement. The Business Case should be agreed to and formally signed off by the Project Sponsor or Steering Committee and all critical stakeholders. The Business Case cannot be altered without prior agreement from the Project Owner/Steering Committee and key stakeholders and related projects. The Business Case would be associated with technical Feasibility Study document which would contain overviews of the product's requirements and initial technical solutions. It should always be produced by a RAP session and is the by-product of the RAP session.

Project Tracking
Project tracking should occur at least weekly and should involve a team-based review session. The primary focus of the tracking session is to determine whether the project is keeping to the agreed Business Case and the project schedule. The team should be using a PC-based scheduling tool Task Form to enter the actual task effort which provides a visual feedback as to the progress of the tasks.

Individual GANTT/Actual progress Mary Jones

Task A Task B Task C

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Project tracking should also accumulate actual progress versus estimated progress and actual effort (costs) versus planned effort (costs). This information can also be entered via the Task Form in the PC-based scheduling tool. The Table Tracking view in most scheduling tools can produce the Gantt chart shown above. Tracking of the quality of the technical deliverables should be undertaken via the use of Inspections or Quality Reviews which are peer-based quality assurance techniques. Until a task's deliverables have been reviewed technically, it is not wise to declare the task complete. However, a team meeting is always the most effective tracking process as it can discuss soft factors that may be affecting success.

14

2007

Agile Project Management A Primer

Project Reporting & Review
Reports should be forwarded to the Project Sponsor, Steering Committee and key stakeholders on a regular basis. There should also be specific phase-end reports produced when major technical milestones such as completion of Product Requirements are reached. Project reporting should focus on the Business Case and the associated project schedule. The Business Case focus ensures that the project management process concentrates of the management concerns of budget, deadlines, resources and so on. The project report should include the following details: has there been any variation in the expectations of project success (Page 3)? has there been any variations in the Business Case (incl schedule) since the last report; if so, is there an updated Business Case for review and approval; have the stakeholders reviewed the changed Business Case; what are the key issues for the Project Sponsor (Steering Committee) to action; any key milestones, deliverables produced during the reporting period; and any major future developments expected in the next reporting period. The Project Report should be treated as a key mechanism for keeping stakeholders aware of the progress of the project. The Project Report should also show the actual progress in the last period against the planned using a GANTT report and the Costs Summary report. Technically-oriented reports such as detailed product designs, technical models and so on should be forwarded to relevant technical support people in the organization. Finally, the project reporting framework should reflect the projects expectations of success (Page 3). For example, if Quality is mandatory for the product and Budget is flexible, then the project report should focus on Quality not Budget.

What senior management really want to know is are there any nasty surprises in the project. If so, what can they do to assist in resolving the issue.

In addition, the project reporting cycle should be driven by the Project Risk. If you are undertaking a Highrisk project, you should have a more frequent reporting cycle than one for a Low risk project

Project Success and Tracking An Agile View

The Success Criteria (Sliders) discussed on Page 4 should drive the tracking of a project.

Project Change Management

It is to be expected that the initial Business Case and associated technical requirements will be subjected to changes during the product development cycle. There are two types of changes; internal - changes arising from within the project team; external - changes arising from stakeholders outside the project team Any change to the initial Business Case must be subjected to formal recording, analysis of the impact and, if required, a re-planning session including update of the Business Case and project schedule. What is critical to note is that the Business Case is a living document. It will change many times during a project and the Project Sponsor must approve all changes to the Business Case.

Project Sponsor
The Project Sponsor is the most important person in the project management world. This person is the person who must have the organizational power and the financial delegation to act quickly and decisively in the overall governance of the project. The main roles of the sponsor include: the assistance to projects in an 'out-of-control' situation; assistance in the development, review and approval of the project Business Case and any changes; review and approval of changes to project staffing, schedule, deliverables, priorities, etc.;
No Sponsor, No Start. Research by our group and the Standish Group, in the U.S., show that the effectiveness of the sponsor is one of the critical factors in project success.

15

2007

Agile Project Management A Primer

decision of major priority of releases/deliverables; high level approval of interim deliverables; review of overall project quality requirements; interface to other areas impacted by project; resolution of inter-project boundary issues; approval of project development strategy; management of the benefits realisation; and oversight of the support and maintenance of the projects outputs.

Project Steering Committee

The Project Steering Committee represents, at an executive-level, the critical stakeholder groups in the overall governance process. While the Project Sponsor is the single point of accountability for the project, the steering committee members expand the governance process by undertaking the same roles as the sponsor. In particular, the Steering Committee provides a court of disputed returns. For example, if there is conflict between two different stakeholder groups involved in the project, the Steering Committee would be able to resolve the conflict at an executive level. In effect, the Project Sponsor should be considered as the executive Project Manager in the sense that he or she makes all the critical management decisions for the project.
The Bag of Money and the Baseball Bat Test. The person who is sponsoring the project must have the right level of financial delegation (Bag of Money) and the organisational power (Baseball Bat) to make decisions quickly.

Organizational Change Management

All projects involve changes to organizational business process, personal power and broader cultural concerns. Agile project management reduces the impact of these changes through active involvement of those people impacted by the change. However, in many projects, meeting the challenges of the broader cultural impact of the project require specialist cultural and sociological skills that most project managers do not possess. However, one powerful tool is to examine clinically the wins and losses faced by stakeholders if the project succeeds. wins look for ways of maximizing these; losses look for ways of minimizing these.

Project Checklist
The following checklist provides the essential questions for reviewing project plans and project development:: is there a clear statement of the project's scope and objectives? is there a statement of stakeholders and related projects? has the appropriate level of project sponsorship been obtained for the project? are the relationships and services involved with the stakeholders and related projects documented? are benefits and costs clearly identified and the assumptions involved in the calculations documented? is there a benefits realisation plan, which identifies how the benefits are to be realized? is there a statement of which stakeholders are involved in the realisation of the benefits stream? is there a clear statement of the quality expectations for the project? is the project's development strategy/events/scenarios identified? are the risks (business and project) involved in the project identified? is there a risk containment strategy included? are the task lists realistic and have relevant experts checked them? are estimates, costs and benefits stated as a series of ranges (best, likely, worst)? has a project schedule been created? are all relevant resource assumptions included? have key stakeholders agreed to the project's Business Case? have any policy, staffing or legislation impacts been evaluated? is there an estimate provided for on-going support and maintenance of the projects outputs?

16

2007

Agile Project Management A Primer

Rough Rules for Veterans
These rules summarize bitter lessons learnt by many battle-hardened veterans: Most projects that fail had failed before they started; These projects were given fixed deadlines before any estimates, requirements, quality requirements and resources were determined and because of this were never planned properly or adequately supported by senior management. It is extremely difficult for a Project Manager to stop a project that is failing; People in a project that is failing will become obsessed with working harder as a result of the energy and ego that they have already committed in the project. Planning and quality begin to be seen as luxuries that the project cannot afford. If you cannot stop a project - it is failing; No matter how close the deadline, planning will always pay back the time required. The "lemming rush syndrome" switches in and people start denying the reality of the project and start believing that working harder can substitute for working smarter. Planning is work - working is not planning; It is easy to substitute hard work for clever planning and communication. It pays to be paranoid when planning a project; Plan for the worst and hope for the best .. there are more risks in your project than you can ever imagine. A well-managed project is generally less exciting than a badly-managed project; The adrenal rush of a project forced to meet a deadline or to solve a difficult problem under pressure is the stuff of heroes and heroines. If nothing has changed in your project - get paranoid !!!! Change is normal in projects. If there have not been any changes to your project [scope, objectives, stakeholders, risk levels and so on] then either you have not been communicated to by your team or alternatively you have been "set up". Your stakeholders are your best friends or worst enemies you decide at the beginning Getting buy-in from your stakeholders is easier than ignoring them and getting them to buy-out. Dont own the project own the process When you cross the line and start owning the project, you begin to alienate stakeholders; you marginalize the sponsor; you lose perspective and, most importantly, you become too protective. All projects belong to the sponsor and stakeholders. You are the person who is responsible for making it happen. What you can get protective about is the process of project management and your team.

17

2007