Visions of a Project Initiation

There have been a few times in my career where projects did not exist, it was all about creating and developing a Product.  With Projects as the defacto software delivery mindset it’s been painful here and there and through that pain I have learnt a lot.

One particular, less painful, point in time was when we were able to stop using  a traditional (Prince 2 style) Project Initiation Documents (PID) and detailed Project Plans replacing them with something much more light weight and Product oriented.

We did this by building trust and gaining influence the Project Management Framework owners whilst simultaneously challenging some of their core principles.

But how I hear you ask? And importantly why did we choose the battle?

The Project vs. Product conundrum?

Projects are concentrated on a short time horizon (some multiple of 6 months perhaps) and can (and often do) create a “get it over the line” mentally rather than that of creating a product that will need to evolve over many years. The “get it over the line” mentality will create focus on “delivering the project successfully” which for many means the scope being met, on time and within budget.

When you have a Product mindset, particularly if you are able to deliver iteratively and incrementally, then it shifts the the focus on what is most valuable to our customers and having funding to deliver this value based upon our success.

This article is not about the trade offs between projects and products (this may come later) but more to do with starting agile product delivery when you have a project constraint. Here is what I said

Project Initiation Document – No. Vision – Yes.

The aim of Project Initiation Documents is to:

“…define the project, in order to form the basis for its management and an assessment of its overall success. The Project Initiation Documentation gives the direction and scope of the project and (along with the Stage Plan) forms the ‘contract’ between the Project Manager and the Project Board.

Contract, urgh doesn’t sound very nice does it when you think of high trust, adaptable agile environments (I am sure to some this sounds delicious, more power to you my friends). If you check out the Prince 2 wiki you can see all of the sections they recommend for a PID and I would say that its pretty comprehensive to the point of overkill. I can hear some people now saying “you’re not supposed to use it as is” and “its a framework and you can choose what you need” and I agree, ish. The problem with the organisation I am thinking of was that the levels of unthinking compliance and/or trying insure yourself against later reprisals meant that people would use each section for fear of a finger pointing later or a lack of information and courage to do otherwise.

When we look at these document requirements through a LeSS Product delivery lens you can see that we answer many of the questions through education of our peers and by following the frameworks guidance.

So our scenario was this; we do not want to create a PID although we were forced to use a Project to get Product delivery underway so we wanted to find a way to create a longer term focus, make clear the users, states the Products goals and defines the success criteria (in some way).  Producing nothing at all (with trust yet to be built)was not an option, instead we tried to build a bridge between the Project and Product worlds.

The Vision

I have often created visions based upon Roman Pichler’s Product Vision board that focus on:

  • Who is the Product for
    • Your actors, stakeholders whatever you want to call them. These are the people you will want actively involved and providing you with frequent feedback and in many ways steering the direction of the Product.
  • What problem does it solve for them? What behaviours do they need to change?
    • This, if anything, should be see as your scope. How can any piece of software be successful if it is not solving a problem or allowing meaningful behavioural change for your target audience
  • What is the value to business?
    • Provides a starting point to begin to define more specifically how the Product will make, save or protect the businesses money
  • What are the features or feature sets required (at a high level) to achieve this.
    • Specify features broadly enables a level of adaptability and emergence as you progress through the Products development.

By using a Product Vision and by creating it collaboratively we reached a very similar outcome to that of a PID. We had to add a few additional artefacts around roles stakeholders but we were happy to tale this trade off.

Project Plan – No. Road map Yes.

Whilst there is great satisfaction for some in admiring their hard work after having a meticulously defined project plan a high degree of detailed up front planning at a point in the delivery when you know the least is rarely ever a logically decision.

So what are the reasons why we plan?

  • To make people comfortable that we have
    • thought about what the foreseeable future will look like
    • Some idea what we will be releasing for each release/milestone
    • remove some risk by thinking through in detail the whole Project
    • Thought of all the people we may need to coordinate and synchronise with
  • To give people a stick to beat people with when we deviate

What options do we have that can provide some of the above and yet not indulge in the folly of a detailed plan? I would like to offer a Road map as an option and in agile an environment I feel it should contain

  • The themes or goals you are trying to achieve (regulatory compliance, increase a specific customer base, reduce manual processing)
  • Add results with targets so you are clear how you will measure your achievement
  • Add big chunky features that are derived from your Product goals (which should be clear on your vision)
  • Keep it super simple, we were trying to avoid big up front planning, what’s the point in making just a detailed project plan with a different name?
  • Make sure it tells the people who are reading a story of the next few steps in your products evolution
  • Collaborate with the users, teams and higher management to make sure you have buy in and you’ve got received, filtered and sorted feedback
  • Don’t be afraid to add a date or a time frame it can help coordinate if you are dependent on parties externally to you and helps create comfort for those who have had some comfort stripped away with the remove of an upfront plan. It also helps the teams as having a goal can motivate (cite)

To Conclude

I’m not saying that PID’s and Project Plans are fundamentally bad, they have their place especially when your delivery is one where the software and the process for delivering it are obvious (by this I mean well understood and predictable). However when you are embarking on the creation of a new product and you are faced with Project Management type requests then try using tried and tested Product management techniques in place of some the standard Project Management artefacts. Not only does this set you up for the Products future it also provides a more lightweight, effective, easily understood set of artefacts bridging some of the communicate and trust gaps that we face.