If I advocate for finding what can go right with your project, and I help you manage the project, I should start with getting a clear understanding of the outcome you expect.  What is the best possible outcome from the time and money and effort you will expend on your project?  Why are you doing it, really?  What will be different, in the best possible way, when you are done?  What do you want the journey from here to there to be like?

Notice, I used the word “outcome,” not “scope.”  I think “outcome” goes beyond “scope.”  Scope is defined by the PMI Project Management Body of Knowledge as “The sum of the products, services, and results to be provided as a project.”  I think that outcome is what you get after you have completed the scope.  Ideally, the scope provides all the things needed to get to the outcome you want.  But, this isn’t always the case.  Sometimes you get asked for one thing, when what they really need is something else.

More often than not, when our clients express the outcome they want, they think about scope.  They say “I need a system that does this…”  When they say that, we should ask “Why?”  Here’s an example:

A state agency hired me to help them manage a project.  They said that they needed to buy a system to automate their program.  Their program provided grants to local non-profit agencies so that they could help people with housing.  The non-profit agencies would find clients, assess their needs, define the work they needed, monitor completion of the work project by contractors, inspect, and pay.  Sometimes the local agencies also kept materials on hand to do simple projects themselves.  The state required the agencies to report on clients served and projects underway or completed.  They had to track costs of the services being delivered in detail.  As the local agencies had many different ways to track their data, reports to the state were inconsistent in timing and content.  The state agency felt that if all the local agencies had the same system, this situation would improve.

The state agency had identified a few systems that seemed to offer the best features and functions for use by the local agencies to manage their programs.  They wanted me to help them vet the systems and manage the acquisition process.  (This next part will sound short, but actually took a few months to work through…).  I asked what they thought the best possible outcome would be.  They said that they primarily wanted better, more timely reports.  I asked if they wanted to provide a level of functionality to all local agencies that would effectively support their business processes.  They said yes, but qualified that by saying that there is lots of diversity out there, and many of the larger agencies or agencies that offered many programs would be reluctant to change to a new system to manage their projects and produce the state reports.  I asked if they were willing to bring about an outcome that would have everyone use a common system.  That would be tough, they said.  I asked whether the outcome they wanted included being the system provider for a mission critical operational system for all the local agencies.  They said no.

We ended up building a system that provided a low level of functionality to be used by local agencies with no system, and included a standard way to collect data from the local agencies with existing systems.  Local agencies could make a choice about which way to go.  The state would be able to control the level of functionality that they would provide.  All the clients, state and local, worked together to define standard data and standard reports.  It turned out that the best possible outcome – getting better, more timely reports – was a less expensive project in terms of money and the level of change than was expected at the start.

This scenario has happened to me several times.  In my consulting reading and work, it is a common theme that the “presenting problem” will nearly always be different than the real problem.  If we are looking for what can go right, we ask our project clients what they consider to be a perfect outcome of the project.  We ask what will make the journey through the project one that best builds partnership and capacity.  Doing this we are more likely to expose the gap between the presenting problem and the real problem.  Give it a try.

Thanks for reading.

Copyright Glenn Briskin and “The Other Side of Risk” 2012