What vs. When?

 

What vs. When?

It never fails to amaze me how many hours are spent trying to wordsmith terms and schedules in order to meet rules of political correctness.   I have spent hours of my career pretending we are developing a project plan focused on including a suite of capabilities to be delivered together, when in reality – there is an imposed constraint (due date) that must be met.  So therefore the question needs to be asked:  Is it a case of WHEN we can deliver all the capabilities, or is it a question of WHAT can we deliver by a certain date.  I’m not arguing one over the other, my argument is that time is much better spent using the Benefits model when there is a dictated delivery date.  The scope needs to be focused on WHAT can be delivered in the timebox.

This is where a well-defined benefits hierarchy helps the program manager.  The benefits hierarchy of benefit, outcome, and capability is a foundation for creating the roadmap and eventually the project deliverables.  Focusing on what provides the biggest benefits – rather than the contents of the "what in this timeframe can be defined" should drive the best decision within the defined constraints. (Let’s assume that all capabilities have the same cost/quality as this information may be implied within the benefit definition and associated attributes).  In the simplest sense, the scope of the project in the given time box can be determined by doing a binary check of each capability and what it contributes to the benefit.   Can we deliver this benefit in this timeframe? 

I know this assumes a logical quantitative world in which there are no pet projects and all people are rational – but it’s nice to dream.   However; in the imperfect world in which we live the capabilities should be prioritized first as high, medium, and low.  I imagine at that point all the lows are crossed off the list and ice boxed and the mediums are put on hold.  Then you should take the high benefit contributing capabilities and rank those as high medium and low.  (High is the same as mandatory).  Then ask the question:  Can all these be delivered in the timebox?  If the answer is no – you must move the time constraint!!!. 

If the answer is yes, you then ask, can it include any more capabilities?  If that answer is yes, you then need to independently rank the mediums and then go down one by one and ask the question: can we do the highs plus this one?  If yes – add it to the list, if no – it gets put into the icebox.

Now somebody will bring up the idea of well if I can have 2 and 5 but not 1, then I want to do that.  This exercise is one of those that sounds nice in theory, but becomes very expensive in practice.  The program manager really needs to make sure that the benefit/capabilities stand on their own.  And if they want to combine them – then the combined benefit is what must be evaluated against the line.  It really doesn’t make sense to spend lots of cycles piecing together different scenarios in order to see WHAT CAPABILITIES  we can get delivered, we should focus on WHAT BENEFITS can we start to realize.  This game leads to the bad practice of putting in low value capabilities just because we can get them in by a date as opposed to looking at the high value capabilities that will drive real benefits.

My daydream is over.  The politics of organizations will drive the game.  Unless a complete OCM project has been implemented that drives the decision model driven by benefits is in place – the games of how many things can I fit in the time box will continue.    But keep the faith program managers – by forcing benefits to be evaluated while these decisions are being made will be worth it when the icebox is opened for the next timebox.