Agile Methodologies…Wanting your cake and trying to eat it too?

When I was first introduced to agile project management a couple years ago through a training program at a past employer, I found myself really excited about the premise of the method and its potential.  Planning short bursts for design, creation, adjustment, and delivery within a short window while working with the client to produce exactly what they want…OR…when they want it…who wouldn’t want to operate this way?

Obviously this process is easier to implement in certain industries and presents numerous challenges in others. Projects that don’t require an immense amount of infrastructure development, and also for projects that lend themselves to being the sum of many small components that can be considered “complete components” on their own, it is a feasible way to manage a project and one that focuses heavily on customer service. 

So where does this method tend to fall apart?  How many organizations have you worked for or know of that are still learning how to properly utilize a project manager?  Now, of those, how many of them have just a basic understanding of project management?  If the organizations you are thinking of are like many others, the understanding and use of project managers probably falls somewhere in the realm of a meeting scheduler and note taker and they tend to not utilize all the talents of their project managers.  This lack of utilization and use of project managers can also produce a skewed understanding of certain concepts and the pattern of behavior to follow trends in project completion and project management flourishes.

Because Agile is not a typical form of project management, one thing that is hard to grasp is you can promise scope, but you can’t promise time.  You can promise time, but you can’t promise scope, but you can’t promise scope and time.  Since the promise of delivering scope and a definitive completion time is built through obtaining the scope details in their entirety and then estimating the time to complete this level of scope ,many believe Agile operates the same way.

Consider the quick explanation of Agile mentioned earlier; Planning short bursts for design, creation, adjustment, and delivery within a short window while working with the client to produce exactly what they want…OR…when they want it.  Within agile, the vendor will work with the client to obtain requests, wants, or needs and will rank these items, placing them in order that represents the clients desired delivery pattern, while also considering any dependencies one item might have on another.  Now, once an item is selected the vendor has one of two options, they can promise to complete that entire requirement, but can’t promise when (they may be able to offer a rough projection, but nothing definitive) they will deliver it.  The other option is to promise a delivery date, but can’t promise exactly what they will deliver. 

Imagine, telling a customer, I can give you a time or I can give you a finished product, but I can’t promise you both.  That is a challenging proposition for many and although a vendor wants to provide value to their clients, plus join a movement to a new form of project management that is called for by savvy clients, they can find themselves telling the client they can have their cake and eat it too, only to fall short on promises which damage the relationship.  The art of managing client expectations and setting the precedent for the duration of the project is key to Agile methodology success.  Explaining the possible valuable gained through the use of Agile delivery methods can offer the client, and the vendor, yet another tool.  Imagine a client that understands they can, in an ever changing market that is accelerating daily, change their direction, focus, or what they do with their cash flow for small timeframes, and can change as the market changes.  How amazing is that potential? 

Instead of waiting years to roll out an entirely new IT system that, from the day it is conceived, falls behind the pace of technological development, a company can implement small components of the system to serve the most pressing needs.  As the project progresses, legislative considerations or internal financing incentives may change (amongt a laundry list of other items) and it could become more cost effective to remote host the IT system thus changing the project completely.  Imagine if traditional project management was being utilized in this situation.  It may become necessary to scrap the efforts already made and start developing a completely new project.  Even though completion efforts had not started, the overhead costs of planning and estimation will have been lost.

Perhaps the hospital, in an effort to become complaint with HIPAA and HIMSS requirements decide to build out a quick portion of the IT system to satisfy the requirements prior to the deadline for implementation.  Once done, they then plan to make a capital investment into the hospital to replace the hospital equipment and integrate these new components with the IT system.  The need to develop a quick hitting project and get started quickly becomes very important. 

There are many reasons Agile can be a great form of project management, but your key is remembering that you shouldn’t commit one of the oldest “sins” in project delivery…overpromise and under deliver.  Managing your clients expectations and setting the precedent before the engagement begins, if using Agile methodologies, that you will delivery either scope or time but not both.  This will make sure the client knows they can’t have their cake and eat it too!

Chris Thompson PMP, SSYB