Agile mindset or “How I Learned to Stop Worrying and Love the MVP” – Part 2

(This article also published on LinkedIn)

In part 1 of this post I introduced a good agile concept.

Minimal Viable Product™

And I showed the drawing below by Henrik Kniberg which had initially made me puzzled about MVP.

You obviously do make a car as in the top part of the diagram. So what was Henrik Kniberg really saying about MVP with this diagram?

In project management terms, it’s all about the difference between outputs and value (and that’s a big project focus area these days). If you want your project output to be a specific car, you should follow the top path. Design, build, integrate. That’s classical project management and the route for a complicated, but understood, problem (like a car).

But the MVP is all about value. Building that car may not be the best thing for your business – there may be an option with more value. Or less cost. If the customer’s need is “to get from A to B”, perhaps even they don’t know the details of exactly where the value comes from (speed, economy, pollution, colour?). You risk misunderstanding the requirements, mis-specifying the product and so just missing the value.

Trying to guess customer value up front is the “faster horses” specification problem (it’s probably not a real quote, but it’s so good…)

If I had asked people what they wanted, they would have said faster horses
(attributed to Henry Ford)

The key then is to explore value. Your customer can’t give you feedback on the travel experience of a wheel or a chassis. They don’t need a part of the “final” product. The MVP is not a stage on creating “the product”, it’s a deliverable which will give some value to the customer and some valuable feedback to you. Ideally the smallest, quickest and cheapest (Minimum) deliverable which can be explored by the customer (Viable).

This is the shift in mindset which makes this approach conceptually different from classical projects. Development is evolutionary. You cannot build in isolation. You must partner, deliver and learn. You must plan for, and accept, feedback

Good news is good news – keep going.
No news is bad news – fix the engagement.
Bad news early is good news

It turns out that Henrik had written a very good explanation, which was missing from places where the picture had been reproduced in isolation. Worth a read at the link below.

http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

One great takeaway from this is how small an MVP can be. How fast and how cheaply can you get some feedback from your customer? Maybe you don’t even need to make anything. The first step to the car could be a bus ticket – enough to add some value to your customer and get some feedback about travel.

I’ll leave the last word to the people who developed MVP about how and why this works and why it’s a different way of thinking from a classical project. MVP isn’t a project methodology, it’s an agile business mindset and a key factor in value-driven organisational thinking.

 MVP is a mindset of the management and development team.
It says, “think big for the long term but small for the short term”

Chapter 3 – Responding to growth

This series of posts is serialising my latest project management book.  As I have posted before, I am taking advantage of a summer break to try writing some project management books.  Initially these covered Planning & Uncertainty and Risk and Agility.  I’m now extending this with a new book on how to embed project management into an organisation.  The latest chapter is below.  As ever, comments are welcome – there is a long way to go yet.

---

Responding to growth

This book is about change. You want to change your organisation’s approach to projects.  And you want to change the approach you are using for a reason.  Perhaps you just feel you could do better – improvement is always a goal.  But most likely there is a sound business reason driving a need for improvement.  And the explanation is likely to be centered around organisational change.

Chapter 1 – Value and Projects

My last post was discussing starting on a new book which looks at how to grow and embed project management into an organisation.  This follows on from my previous project management books – one on Planning & Uncertainty and the other on Risk and Agility.

---

The challenges of implementation

Such a range of different approaches and ideas can be disruptive to an organisation. With no overall picture, one group may adopt one approach and another take a different direction.  Language usage diverges, ideological disputes occur and the organisation risks getting distracted from the overall objectives.

Finding a cloud in the silver lining

My book on Project Planning, based on the learnings of the teams with which I worked, is now published. It’s good to see real physical copies and you can find it on Amazon.  Thanks to those who have fed back comments.  Please get in touch through LinkedIn or leave review comments – I’d be delighted to hear what people think.

My last post introduced a second book, covering Risk and agile planning in more changeable environments.  This is progressing well with a draft in review and I hope to have this also published soon.  As before I’m posting chapters to this blog and the second instalment is below.

---

 

Managing Risk is natural

Risk Management is not an esoteric project management practice. Like planning, it is as natural as breathing and we all engage in it every day.  Look at the example below, which represents Risk Management in normal life.

Preface – Risk and agility

If you’ve been following this blog, you will know that I know have a published book on Project Planning, based on the learnings of the teams with which I worked.  In this post I’m introducing a second book which will be published soon, I hope.  As with the previous book, this is inspired by the teams with which I worked at ARM and the project approaches that we developed.  The new book extends the ideas on project planning into the domains of Risk and agility.

A book extract is below and as before I will be posting chapters to this blog.

---

This book is a sequel to “Value-Driven Project Planning” (ISBN 1-5330-5992-6). My previous book shared some of the learning and experiences of teams that I have worked with.  It covered effective project planning approaches and outlined four key sets of project management tools for dealing with different environments.  I refer to these as “The four horsemen of project planning”

Chapter 1: What is Planning?

Following on from post about starting writing a book on project planning, this extract introduces planning as an approach.  As ever, feedback is welcome – for corrections, comments, ideas, please add comments, contact me on LinkedIn or mail me direct (for readers who know me).

Do we need another project management book?

In the last few years I’ve developed and run a lot of training around project best practice.  I’ve found there’s a need for pragmatic advice to help individuals on projects succeed.  So I’ve decided to take the learnings from the training and turn them into a book.  I plan to publish this in sections in my blog and, once complete, to make it available on Kindle.  Maybe also in print form.

Does the world need another project management book?  I don’t know.  But I do know that I worked with some great teams and we learned together and I’d like to share those learnings.

I’d welcome feedback and comments either from those who have been on my training or those who have not.  I’m sure the content will evolve, so see this as an early draft.  To discuss, either add a comment to this blog or contact me on LinkedIn.

---

Preface

We read about failing projects every day – building projects which seem to have gone out of control, IT projects that seem to leave companies in a worse state than they started, change projects which spend money but seem to have no effect. It is easy to see the world of projects as being in crisis.  Yet more and more organisations are delivering value through projects because there are strong perceived benefits to this approach.

Building Better Buffers

I was talking to one of the presenters at Project Challenge about the difficulties around Uncertainty Management. We agreed it was a gnarly area, not least around use of language.

I posted on this blog a little while back about the use of date pairs as a communication method for project uncertainty.  The gap between the “red” (plan) and “green” (commit) dates is known as a “buffer”.  But why do buffers seem straightforward but so often end up (as in this blog’s picture) in flames?

One problem is that buffering still seems not to be seen as mainstream project planning.  You often see it described as a “niche” approach tied to the Critical Chain methodology, which has other complexities that can limit adoption.

There still is controversy over the merits and pitfalls of the CCS/BM methodology

PMI article

This posting isn’t a critique of Critical Chain (CC) as an approach.  CC is being used very successfully and includes features that I like (such as buffering, although I don’t see this as specific to CC), some that I’m unsure about (such as scheduling tasks as late as possible) and some that seem a poor match to my own experience, such as:

Critical Chain Project Management recommends that task estimates are cut to half the length of a “normal” duration

Goldratt

Buffering is linked to the concept of a contingency plan which goes right back to the early days of construction, when budget would be held to cover the project uncertainty, especially in bidding situations.

The construction project at the left clearly had too little contingency planning, resulting in a rushed finish…

 

 

 

 

The critical path method (which dates back to the 1950s) added “float” – the idea that some tasks may be protected by the plan structure from slips impacting the end date.

Float
The amount of time that an activity may be delayed from its early start with out delaying the project finish date

A Guide to the Project Management Body of Knowledge

But what is a “buffer”?  It is clearly related to the forced introduction of float, but I’m not sure I’ve seen a clear definition [can anyone point me at one?].  I would suggest:

Buffer
An available but unused capacity of time, cost and/or work added in to a plan to limit the impact of planning uncertainty

Jay’s definition

Now that may be a bit more flexible than some interpretations, and covers the different dimensions of the “Iron Triangle“.

• Typically buffers are shown as a schedule buffer, with a committed date later than the planned date to allow for uncertainty in the planning.
• Work buffering would be the availability of extra resource and scope buffering would be including uncommitted features in the plan.
• Scope buffering is especially important as it is the approach used in Agile plans, where the schedule is fixed but features can be dropped to manage uncertainty.

When I started managing projects at ARM, project schedules would just include all known tasks at the expected durations, giving you a “best case” end date:  Anything else was ruthlessly stripped out.

Best Case End Date
The earliest date that you cannot actually prove is impossible…

Jay’s definition

Unsurprisingly, on-time delivery was rare, as any task overrun pushes out the end date with little capacity to recover.  Introducing buffers and committed dates helped stabilise the projects and make them achievable.  However, organisations have typically adapted to “padding” task estimates and buffers can be a challenge to the organisation’s traditional way of working.

The concept of seeing visible buffers flies against the standard operating process in most organisations

Project Management Theory and Practice, Gary L. Richardson

The key step is to include this in the culture and move from buffers being hidden, through buffering being allowed to them being expected (“explicit buffering”) and questions being asked if a buffering strategy is not used.

Don’t underestimate the culture shift here and it took some years at ARM.  Explicit buffering is powerful as it lets you understand the real situation with clarity and a chance to exploit opportunities, while giving real and trackable protection on commitments.

 

 

 

Project Challenge Spring Learnings

This week saw Project Challenge Spring Show 2016.  Always worth a visit to see what is happening in the profession across training, standards, tools etc.  And some good presentations.

As ever at these events, I ran into some old (and new) friends.  I met Lindsay Scott of Arras People and PMO Flashmob, whom I’d only “met” online (“PMO Flashmob” has always struck me as a great concept and one of the most unlikely of word pairings).  And I bumped into Andy Taylor of People Deliver Projects, my favourite training team after some challenging sessions over the years with ARM.

What presentations did I see and what did I learn?  Well, with three parallel tracks there’s always some picking and choosing, but I’d pick out:

How should we adapt our approach to developing project professionals?

Clearly a big topic area – how can we best develop teams of project managers?  Projects are getting more complex and the project manager role is becoming more complex.  Skills are in multiple categories:

• Methodologies (such as Prince2).  There’s clearly a big industry training in these as could be seen around the halls at the event.
• Tools (such as MS Project).  As the tools become more diverse and a project manager may be using a wider range of these, the training can become more extensive.
• Processes.  The key tools of the business – Risk, Planning, Control etc
• People and communication skills.  More projects being multi-national with new dimensions such as open source making this even more complex.
• Business level skills.  Portfolio planning, benefits management etc

The other dimension here is that delivery of training is more complex.  Classroom based training has value, but needs to be balanced with on-the-job support and coaching.  Delivery methods become more complex and need to be so as teams become more distributed.

The key takeaways for me were below.  From the training that I’ve managed in our Centre of Excellence, I’d say we’ve done OK on these, but the last has been the most challenging.

• Training needs to be targeted at the right people, attending because they need the training (for their stage of a project or a career) and not blanketed across an organisation.
• Training needs to be tailored to the organisation so the language and context is what the audience understand and can apply.
• It really helps to have a trainer who understands the organisation and can discuss around the material and not just teach the theory.
• As data becomes ever more accessible, teaching facts becomes less valueable (yes, there is a Prince2 app, probably several).  Teaching what to do with the knowledge is most powerful.
• Training needs to be followed and bedded in with enough support as people use it.

The hidden secrets to increase your value

This one sounded a little over dramatic but introduced the “PS Professional” competency framework around aspects of the project manager role, split into:

• Athlete – Personal Effectiveness
• Executive – Understanding the Business
• Rainmaker – Commercial and Sales acumen
• Authority – Technical project management
• Catalyst – Using the organisational environment

I admit when I first saw it the names seemed a bit “cheesy” but actually it worked well as a presentable concept.  I could see this communicating the key skill areas for project managers quite well.  For each area there are three skills and three levels giving a 5x3x3 competency matrix, drawn as below.

More on this here.

Winning through Project Portfolio Management

This was a really thought-provoking talk from Antonio Nieto-Rodriguez, Chairman of the PMI.  And a great example of Risk Management as Antonio had been stranded in Brussels due to the tragedy there and had to present by Skype.

Portfolio Management is a really hot topic and so Antonio’s views on this were very interesting.  He focussed a lot on the difficulties in tying Project Management in to the business.  The Harvard Business Review, bible of board members, has published nearly 5000 articles on Marketing, but less than 300 on Project Management and less than 200 on Risk.

In many ways this makes Portfolio Management a challenging but critical layer as it joins the two groups.  It also suffers from tension between running the business and changing the business, with projects generally covering the second.  Running the business focuses on efficiency and repeatability, while projects are one-offs needing a flexible approach.

It was great to hear some of the bugbears of my own experience being discussed.  Every small item being raised as a project for example.  This adds overhead and also devalues the project process, so in his organisation he introduced a size threshold below which you “just do it”.

Another key area that he discussed is how to track project performance and I think I’d have come out with the same top list:

• Lack of reliable data, consistency and definitions
  • Antonio proposed aiming for 80% consistency being “good enough” and then continual improvement beyond that point.
  • I took a similar approach when we introduced new project tools – focus on consistency up to around the 80% point, but then you have to slow up and let people run their projects.
• Fear of being punished, leading to faked reports
  • A tough area.  Antonio referred to “using reports to gain support” and this is a really important part of effective project culture.
• Poor quality of business cases
  • Glad to see this on the list as I think many organisations struggle here.  A project will only realise benefits if it does the right thing.
• Multiple systems with incompatible data standards
  • The approach proposed here is also the one that we have headed towards which is to have unified reporting, not enforce unified systems.  So the ability to build a data warehouse across multiple systems is important.
• Focussing on the easy indicators, ignoring the true benefits
  • Measuring benefits and leading indicators is hard and needs experienced people to develop the measures.  It’s so easy for an organisation to fall back on what is easy to measure.  To quote someone from my own organisation “if you give me 10 measures, I’ll give you success on the easiest 9”.

Managing Agile, Waterfall and Hybrid projects

This talk was about how to manage combinations of project types in one portfolio and is an area we’ve really focussed on lately.

When I looked around the event as a whole, it was interesting to see the balance of tools being presented.  Gone are the days when people presented scheduling tools – they may have a Gantt Chart, but only because everyone else does.  And also there’s less people with task management tools, which were the big market at the event 5 years ago.

The focus seems to be on Portfolio Management and in particular on how to present project complexity to the company management.  The talk was by Ninth Wave who develop portfolio management tools.  They’ve clearly come from a Portfolio background and were very interested in how you encapsulate project types so your portfolio can function and report across multiple types, leveraging the benefits of each.

This had led to them building scheduling tools and task boards into their tools (as well as interfacing with others).  Interesting because it matches the model I see that HOW the project is run becoming far more a project decision (“you want waterfall delivery with agile platform development and kanban sauce?  Certainly sir”) where the practitioner can choose situationally.

The State of Project Management Survey 2016

The Association for Project Management (APM) Project Management Office (PMO) Specific Interest Group (SIG) have published their first annual “state of project management” report which can be found here.

As might be expected, it’s an interesting read.  It’s UK based and polled 686 individuals across 317 organisations.  Of these 60% had 11 years or more of experience and 70% had Prince2 qualifications.  So a pretty experienced sample.

As often happens in surveys of project management I think we see a hierarchy of complexity in how projects are managed.

Project processes are strongest around deterministic (classical) project management such as scheduling.

 

 

This becomes weaker when we look at the management of uncertainty, here the application of Risk Management.
This tends to need a higher level of maturity to do well.

 

Also telling is the chart of which processes are most difficult.

At the top of the chart are the processes below.  You will see they are all “cross-project” processes, which apply at a group or program level, rather than to a single project.

While the processes that relate more directly to projects themselves and to classical project management are at the bottom of the list.

This suggests the “building blocks” of projects are relatively well understood, at least compared with the challenge of integrating into the organisation.

The survey also looked at measures of project success, of which the key one is probably benefits realisation.

Do you remember the Standish Group “Chaos” report of 1994?  That reported 16% total success, 31% cancelled and 53% partial success.  I’m not sure the numbers have changed that much in this diagram…

 

 

There’s some discussion here about the role of the PMO (Project/Program Management Office).

There seems to be an ongoing discussion of whether a PMO has a “lifetime” of 4 years.
The survey includes the graph here of the duration of a PMO.

 

 

This is quite interesting data, if a little limited to draw strong conclusions.

Let’s redraw it in Excel.  When we fit a curve to the PMO ages we see it’s a pretty good fit to an exponential curve.

This suggests maybe a constant failure rate of around 25% a year, rather than a “4 year threshold”.

A constant failure rate of 25% per year is quite different from a fixed lifetime.  Maybe we should be thinking less about a PMO having “built in obsolescence” than needing to keep demonstrating value to survive.  With 25% of PMOs failing each year this suggests a focus on reinvention and keeping relevant.