Managing Expectations on Projects -Agile Mindset, Waterfall Mindset

Few things can create more tension in a project than pushing back a deadline. 

It can create instant anger between a project sponsor and the project manager. It can even filter down to the people working on a project. Resources end-up choosing a bad-guy: the project sponsor (”she doesn’t get it”) or the project manager (”doesn’t know what he’s doing”) -while all the while risking being cast as lazy or incompetent because the deadline is being blown.

Often, the source of the anger can be traced to differing expectations on how the project should unfold over time. 

Both the sponsor and the project manager likely realize that nothing ever goes as planned, that hiccups happen.  The frustration comes in different expectations on the effect of hiccups.  That is, there are different answers to the question of ”what does this problem mean to my project?”

One side (often the sponsor) expects that a hiccup means that the project will be delivered on-time, but on a reduced scale (less functionality, less features, smaller scope).

To the other side (a classically trained project manager, say) a hiccup means that the project will be delivered as planned, just later.

This dichotomy in expectations mirrors a central difference between two major schools of project management methodology. The two schools are Agile project management and the classic Waterfall approach to managing projects.

Understanding this difference can help pin-point the source of frustration on projects when a deadline is missed. 

By using the language of Agile versus Waterfall people can more clearly explain where they’re coming from at the start of a project -and hopefully reduce the anger and frustration that can arise in the middle of a project, when the project takes longer than planned.

Agile and Waterfall have different views on the lifecycle of a project. 

• Agile tends to look at a project as fluidly ongoing, evolving through a series of iterations. 
• Waterfall looks at projects as having a defined end-point, the delivery of a pre-specified set of requirements.  

AGILE PROJECT MANAGEMENT MINDSET 

Agile aims to deliver something that can go live, in a relatively short period of time, collect data or feedback, go back to the drawing board, deliver again and relaunch. It keeps iterating until a further iteration is no longer necessary or useful. But throughout the process, at every step of the way, something ”live” is being produced and delivered.

Coming from an Agile mindset, if a hiccup happens, the next iteration gets pushed off. But at least there’s something live that can be worked with.

WATERFALL PROJECT MANAGEMENT MINDSET 

The Waterfall approach starts by spec’ing out everything the final deliverable should be. It begins with the assumption that the research has been done and the data analyzed. The final project deliverable represents the best-guess of what should work to fulfill the goals of the project sponsor. In a Waterfall, the project moves sequentially through its lifecycle, cascading downward from specification, to design, to development/production, to testing and going live. The deliverables don’t exist, even in a rudimentary form, until the production phase is reached.

Coming from a Waterfall mindset, if a hiccup happens, the launchable deliverables get delayed, the whole project gets delayed, until the hiccup is resolved.

REDUCING FRUSTRATION

Both Agile and Waterfall have their place in getting projects done.  

But for the purposes of reducing frustration and anger on a project, they are only useful tools to raise awarness of differences in people’s expectations -differences that are the source of tremendous tension.

This awareness can facilicate healthy communication, and reduce the source of frustration before any problems arise. When a problem does arise, the project sponsor, project manager (and even the team) can be on the same page as to what to expect.

Everyone can have the same answer to the question “What does this problem mean to the project?”

By the way, it doesn’t matter if  people know the difference between Agile, Waterfall or the Bay Bridge -if it complicates things, or requires more explanation that its worth, leave the fancy terminology out. 

The important thing is to talk about the differences in expectations on project lifecycles that can and often do exist.

          

This entry was posted on Tuesday, January 23rd, 2007 at 11:27 pm and is filed under Workplace, Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.