Agile-Based Project Management

Agile-Based Project Management

Milestone targets will help reveal true progress – or failure

Many failed projects suffer from the same tactical mistake: doubling down on failure in the hope of a different outcome. This type of behavior has been well observed under the guise of the Gambler’s Paradox—continuing to gamble in the hope of recouping losses; resulting in even greater losses. Good project management, on the other hand, entails tracking down and detecting when a project is being derailed and then planning appropriate, timely remediation or even changing direction. This is why it’s best to properly partition a project into discrete and well quantifiable milestone targets. At least in this way, if something fails, it will only affect a portion of the effort.

Focusing less on micro-managing every activity and more on enabling the timely delivery of milestones that break-down the project into specific sub-projects is a more flexible approach.

Handling issues occurring at a sub-project level is less difficult. Also, having stand-alone milestones allows for possible early delivery of actual functionality. It is even possible to create some milestones to serve as a “canary in the mine”, as long as these milestones do not create unnecessary pressures or distract from the main path of the project.

Needless to say, the key to tracking and assessing the status and impacts of a project’s dynamic is the project management function. However, there is the mistaken idea that anyone with working knowledge of MS/Project can become an IT project manager. The fact is that in the world of IT, delivery managers with systems and software knowledge and background have traditionally been more successful in the project management role. Perhaps the reason for this is because this type of project manager is more able to assess the health of a project against actual milestone deliverables rather than via traditional Gantt charts with red-yellow-green status colors. This semaphore style might look good on status reports but does little to ascertain the true project status.

When establishing the project management governance, keep in mind that there are projects and, well, there are projects. Smaller projects have to be handled in a manner that assures the necessary ingredients for success are available to the team leader with a minimum of red tape. Smaller projects can benefit greatly from rapid application development methodologies¹ and from early prototyping. In addition, smaller projects better align with the iterative approach favored by Agile methodologies. Partitioning a large project into smaller areas of work also facilitates the potential testing and introduction of innovative solutions while minimizing risks. However, partitioning should not be viewed as “fragmenting”. There is science and art in the way to partition a major initiative while maintaining a holistic and integrated view of the whole. In this sense, the principles followed in Agile development (planning game, small releases, simple design, etc.) also apply to milestone-based project management.

What defines a small project?

Well, having no more than five people working on a deliverable for a maximum of four months is as good a metric as any. If the cost of this type of project exceeds the one million mark including labor, hardware, and software capital costs, then it should not be handled as something small.

Then there are the medium size endeavors. These are projects that can take up to a year, or slightly longer if the powers-that-be are willing to take Prozac and give you a bit more leeway. The core development teams for this type of project should never exceed the magic number of twelve. These projects tend to fall in the ball-park figure of around two to three million dollars. A medium size project needs to be managed with a savvy combination of high-level project management controls and the appropriate placement of deliverable milestones.

Larger projects should not even exist. Why not? Well, a large project should be properly broken down into as many small and medium sized projects as possible. Ultimately, a large project should only exist in the PowerPoint® bullets of those responsible for your company’s public relations, in the minds of marketing (“Version 3 of our Super-duper product available by Christmas!”), and in the radar of the very small team responsible for the integration of all the various moving parts.

Clearly, the failed initial launch of Healthcare.gov was an example of a humongous project that was managed on a task-oriented basis. It had only one real milestone: Go into production by October 1, 2013. We all know what happened next. The story would have been turned out a lot differently if a milestone based approach had been followed.

So, what is agile-based project management really all about?

Basically, it’s the definition and tracking of measurable, well defined milestones. Note that we are not suggesting that the need to plan for tasks goes away; just that the project status should not be measured vis-à-vis the degree of task completion or the number of hours worked on a task, but rather against the milestone’s success or lack of thereof. Milestone management is based on outcomes as compared to the actual business requirements the project is attempting to solve.

The difference between a milestone and a traditional project management event is that the milestone should stand on its own as a visible deliverable. Visible is the operating word here. Completing a piece of code is not a milestone. Completing a working prototype or demonstrating a working sub-component of the deliverable are proper milestones. An eye-candy demo is not. If the event is something that can be shown to anyone outside the core development group, and is considered to be at least a partial success, then it qualifies as a milestone.

Tracking projects via milestones has a number of benefits:

• Missing a milestone might be a clear signal that the project is not on track, but the impact of the delay can be contained in a timelier fashion
• A successful milestone motivates the team by providing success checkpoints
• Milestone deliverables with stand-alone utility can deliver actual benefits sooner
• A successful milestone helps motivate the project sponsors to continue their support of the project even when faced with budgetary constraints

Conclusion

There is no way to sugar-coat a missed milestone. While this should not necessarily spell gloom-and-doom, a project with two or more missed milestones is a project that needs to be seriously reviewed and revised.

To be sure, it’s always best to allow room in a large project to anticipate the failure of a specific component and to adjust for the overall delivery because of this failure. The solution to this type of quandary might range from starting again from scratch (assuming the initial implementation was proven wrong), to completely eliminating the subsystem and remediating by providing a suitable minimum set of capabilities from other subsystems.

Ultimately, agile, milestone-driven project management will be superior to the traditional task-oriented project management style.

¹NOTE: Use of Agile methodologies should apply to the actual software development process; not to the architecture and design-making processes. Using pseudo-Agile approaches under the mantra of “code now, design later” often results in failure.

To learn more about Wavestone US’ services, visit http://wavestone.us/capabilities.