In the literally 1,000's of pieces of correspondence I receive or send monthly, I came in contact with Impact Mapping, Gojko Adzic. At the same time I got an email from a person I met while speaking at last weeks conference (International Cost Estimating and Analysis Association).
This small book has a powerful concept that matches closing with a paradigm used in our domain Integrated Master Plan (IMP) and Integrated Master Schedule (IMS). The IMP/IMS approach to program management starts with a set of Program Events that assess the increasing maturity of the program itself and the deliverables that make up the program.
The IMP is derived through a Systems Engineering process is eliciting the Measures of Effectiveness and Measures of Performance for the outcomes of the program. The things that fly, swim, walk, or drive away after the program is complete. These measures are guided by Key Performance Parameters.
What is of interest is not the IMP/IMS (that's talked about in many other posts) or the book itself (which should be in the shelf of every software and IT Project Manager), but the notion of defining what done looks like in units of measure meaningful to the decision makers.
This last phrase of course is the basis of my own book Performance-Based Project Management® which shows how to put that phrase to work.
But that's not the point either. The point is — the notion of defining capabilities connecting these capabilities together to solve a complex problem, eliciting the technical and operational requirements that enable the capabilities to be capable, then collecting all these capabilities and requirements into some model to assess the impacts of each component on the other components to inform the decision makers on the probability of success of the project is actually very rare.
Why is it Rare?
It is rare, because in our technology world we start on the wrong end of the problem. Tom Poppendieck says it best in the forward With few exceptions, software development work has long been separate from other parts of the organizations it supports.
This disconnect is not a development problem. It is not a business problem. It is not solved by rapid feedback, since rapid feedback in the absence of a clear and concise description of what DONE looks like in those pesky units of measure meanigful to the decision makers - is just rapid production of software that doesn't solve the real problem.
The Real Problem
The real problem is neither those paying for the solution nor those providing the solution have a shared understanding of the vision and mission that will drive the needed capabilities before starting work. The notion that the requirements will emerge is used in the agile community. But in fact there is no actual test of that notion. Next week, June 17th, Jim Highsmith is speaking here in Boulder. It'll be interesting to hear what he says about emergence.
The real problem is without some shared understanding of mission and vision and the units of effectiveness and perfomance, no project is going to fulfill its goal without waste of time and money. From Joint Strike Fighter to the internal IT project, work without a definitized set of capabilities, simply spends time and money searching from those through rapid delivery of technical outcomes.
It's a solution looking for the problem. Rapidly producing a solution for sure, but looking all the same
So buy the book, it's a good read. And it'll improve the conversation around what DONE looks like. But it's only one piece of the solution to a very complex problem in product development.
- What do we want to system to do in the broader business process sense?
- Do we even have a business process?
- What are we willing to pay for this system?
- When do we think we will need this system to provide the capabilities we think we have identified?
- How can we test the notion of the needed capabilities, the cost, the time to get feedback that we're on the right track for each of those?
The answers to these questions are hard to come by for all the right reasons - they're hard.
So we focus on the things we know about and many times the things that have little to do with the actual problem of producing value in exchange for money.
But buy the Impact Mapping book, buy my book, buy a Balanced Scorecard books and read articles, buy a strategy making book. Start with the hard part first - what does DONE look like.
One Small Glitch
On page 27 of Impact Mapping is a topic of adaptive planning. Adapting your plans to emerging situations is called planning. Plans are meant to reveal the future and therefore must be changed when encountering the reality of the situation.
The picture used is of a person building a Dog House, then bringing a dog to the Dog House and realizing the Dog House is too small. Then having an ideas for a larger Dog House.
This is bad project management and bad planning. If you are going to build a Dog House, you'd better figure out what size dog will fit in the Dog House before starting to hammer. If you have a dog and build the Dog House too small, you're a poor engineer. If you build the Dog House before knowing what size dog will fit in the Dog House, you're a bad planner.
Other than that the Impact Mapping book is a must read.
Related articles
