Managing Agile Projects

Traditional IT project management has grown up around and closely aligned with the Waterfall software development methodology. As with most engineering projects the final product to be delivered is scoped, designed, built, tested and implemented – in that order. This is OK if the client knows what it needs precisely and the number of changes is relatively small. Waterfall falls down (pardon the pun) if the project is a quest to achieve an objective and everything changes routinely.

Agile seems to be an ideally suited methodology for developing software in these circumstances but if the work is also a project how should the PMBOK® Guide processes be applied? This blog will outline some ideas at a high level; later blogs may dig into some areas more deeply.

The PMBOK® Guide 4th Edition (2008) has 8 knowledge areas:

Project Scope Management
Traditional project management expects scope management to define the output. In an Agile project the final outputs should be defined in terms of achieved capabilities, how the capability will be achieved will be discovered along the journey.

This makes ‘Verifying the Scope’ interesting. There needs to be clearly defined way to assess if the capability has been delivered. How do you measure a ‘user friendly interface’? It’s not impossible to do but how it’s done needs to be clearly defined.

Change control is also more challenging, as is configuration management.

Project Time Management
Ideally time should not be an issue if the objective is to achieve a required capability. In reality there are usually deadlines.

In an Agile project, scheduling and workflow become closely aligned. The key requirement is an overall system architecture that defines the sequence modules need to be built in to allow progressive testing and implementation of capability. The software architecture defines the build sequence that defines the schedule.

Scheduling is at a much higher level though. A ‘sprint’ is likely to be a single activity of 1 to 2 weeks duration. The sequencing of the ‘sprints’ and the number of sprints that can operate in parallel define the resource requirements and the project duration.

Project Cost Management
Agile projects have to be based on a cost reimbursable system. One tool designed to include a degree of competition with the ability to properly compensate the contractor for its work is southernSCOPE the methodology requires tenders to bid on a project at a $ per function point rate based on a project description and the estimated number of function points. At the end of the project the same independent person who prepared the initial estimate, re-counts the function points and the price is determined.

Project Quality Management
This is probably easier under Agile; quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Human Resource Management
Basically remains unchanged but the skills of the people needed for an Agile project are likely to be different.

Project Communications Management
The level of trust needed to run a Agile project is much higher than a traditional project. Effective ‘real’ communications in all directions are essential. This is different to producing project reports! More later.

Project Risk Management
Recognize you are on a journey focused on delivering value. Significant time and cost contingencies are needed and should be used to optimize the value of the final product. More later!!

Project Procurement Management
This should not change significantly BUT the procurement process needs to be aligned to what it is buying. Agile works in a collaborative partnering space. In the engineering world these are call Alliance Contracts. Traditional contracts will not support Agile delivery methods.

In conclusion: align the PMBOK to an Agile project delivery method and the overarching PM process will enhance the probability of success. Treat an Agile project in the same way as a traditional Waterfall project and the PM processes will guarantee failure!

To help bring effective project management into Agile projects, PMI have launched the PMI Agile Certified Practitioner (PMI-ACP) credential. The certification is designed to:

• Demonstrate to employers a credential holder’s level of professionalism in agile practices of project management
• Increase their professional versatility in both Waterfall and agile techniques
• Offer a certification that is more credible than existing entry-level, training or exam-only based offerings

The requirements are:

General Project Management Experience: 2,000 hours working on project teams. These hours must be earned within the last 5 years.

Agile Project Management Experience: 1,500 hours working on agile project teams. These hours are in addition to the 2,000 hours required in general project management experience. These hours must be earned within the last 2 years.

Agile Project Management Training: 21 contact hours; hours must be earned in agile project management topics

Pass the PMI-ACP Examination: Tests knowledge of agile fundamentals

For more on the certification see www.pmi.org