Project Management

What? You don't know why you are doing your project?

From the The Agility Series Blog
by
The Agility Series focuses on agile and agility across the organization not just in software and product development. Areas of agility that will be covered in blog posts will include: - Organizational Agility - Leadership Agility - Strategic Agility - Value Agility - Delivery Agility - Business Agility - Cultural Agility - Client Agility - Learning Agility

About this Blog

RSS

Recent Posts

Guiding Principles for an Adaptive Organization

Reflections on 40 Years in IT - Agile by default!

InfoQ Podcast Interview of me on The Agility Series, Cultural Agility, and more

You might be a management red-neck if…

Strategic Debt  — What it is and how to avoid it

Categories

Agile, agile, agility, Benefits Realization, could be agile...sort of, Cultural Agility, culture, humour, Investment Decisions, Leadership, mindfulness, not-agile, outcomes, Outcomes Management, Outcomes-focused Agility, outcomes-focused agility, PMO, Professional Development, Resilience, Scrum, servant leadersip, SOA, stategy, strateggy, Strategy, strategy, Sustainability, Value Management

Date



Subtitle: Outcomes-focused Agility - Story Mapping our Strategic Intent

I am going to make a bold statement.

More than 50-60% of project managers don't know why they or their project teams are doing their projects.

How can I possibly say that? Surely there are charters and project plans with backgrounders and scope statements? Maybe there are. But that does not mean they know truly know why the project is being done.

Why say that?

Numerous studies over the years have shown project failure rates of 50-60% (some studies are higher and some are lower to be sure). Likewise, where software development projects are concerned, it is estimated that 60-70 per cent of features built are never used or rarely used. Both of these statistics (and others) point to a lack of clarity on why the project is being done in the first place; The sponsors, the teams, the PM, and others really don't have a clear articulation of why they are doing it.

Another factor is that most projects are proposed - that is, someone has an idea for a project, they then write a business case or lobby the executive ranks to get it approved. Some even tie it to strategic goals or objectives. But that still does not mean they know why it is being done.

Projects focus on Outputs

Most project management books, when they distill the essence of project management, will show a diagram similar to the one below. Some project management practices may also refer to the Activity box as Tools and Techniques, but the premise is basically the same; Inputs are consumed through some form of Activity to produce Outputs which are the project’s deliverables.

While this model is simple, it is focused on the wrong things. It does not answer a very important question – why is this project being done? Focusing on why establishes the desirable Outcomes that the project would create if it were successfully completed.

Agile approaches are not immune from this phenomenon as they also start with the Outputs (i.e. deliverables, products, features, etc.) and then identify the activities and inputs needed to create them. The difference between traditional and Agile is in what the activities are and how they are accomplished. But it still does not answer the why questions.

Interestingly, normal business operations and projects both focus on using inputs to activities to create out-puts. Ditto for business processes work. None focus on knowing why.

Outcomes – The Source of Why

Outcomes Management enables organizations to define and use specific indicators to continually measure how well services or programs are leading to the desired results. Outcomes Management is used extensively in health care (it did start with Florence Nightingale after all) and the not-for-profit sectors.

For IT, it was articulated in the book “The Information Paradox” by John Thorpe of DMR in 1998. Before the book was published I was working for DMR and we were taught the Benefits Realization approach (based on what was in the book) as part of being consultants. It was also embedded into the “ValIT Framework” from the IT Governance Institute, with John Thorpe as the lead author.

Some of the questions we can ask ourselves and our Business colleagues to help us identify desirable outcomes include:

  • Why do we want to affect the current situation and what would a new set of outcomes look like?
  • What will it look like when we achieve the desired solution or outcome?
  • Why do we want to affect current behaviours?
  • Why are we doing this?
  • What benefits would we get if we achieved a particular outcome?
  • How will we measure the benefits?

There are two important ideas to understand about Outcomes – their type and their timing which we look at next.
Outcomes Types
There are three basic types of Outcomes that can be achieved from any action we can take as shown below:

  • Good and Intended: Ones that we planned for and intended to happen
  • Good but Unintended: Ones that we did not plan for, but that have a positive effect on the organization or its Customers/Clients
  • Bad and Unintended: Ones that we did not plan for and that have a negative effect on the organization or its Customers/Clients

The first two types of Outcomes are ones that are desirable – that is they have a positive effect.

The last one is an undesirable Outcome type that we would wish to avoid. There are everyday examples in the non-project world of Outcomes that are bad and unintended. For example, introducing a new species into a habitat to overcome one particular problem with another non-native species can lead to the new species becoming equally invasive and also destroying native species’ which clearly was not an intended consequence and is not desirable.

We try to maximize the first outcome type, hope we get some of the second type, and try to avoid the third outcome type entirely.

Outcomes Timing and the Outcomes Map
Outcomes also have different timing. One of the concepts that was introduced by Thorpe in his 1998 book was the Results Chain (aka Outcomes Map) as shown below:

Posted on: October 13, 2016 07:17 AM | Permalink

Comments (5)

Please login or join to subscribe to this item
avatar
Markus Kopko, PMP Principal Project Management Consultant| Karer Consulting AG Hamburg, Hamburg, Germany
thank you very much for this interesting contribution

avatar
Lawrence Cooper Creator, Lean-Agile Strategy| AdaptiveOrg Inc. Kanata, Ontario, Canada
Markus - glad you found it useful.

avatar
Karthik T Senior Engineering Manager| Nike Bangalore, Karnataka, India
Good article, thanks for posting.

avatar
Alaa Hussein Program Manager| MEMECS Baghdad, Iraq
Thanks Lawrence, great article!

avatar
Mansoor Mustafa Senior PM| Government Department Rawalpindi Punjab, Pakistan
Thanks for sharing. Great read.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Too many pieces of music finish too long after the end."

- Igor Stravinsky

ADVERTISEMENT

Sponsors