Should projects always be product-orientated from the start?

Question

I've been learning the PRINCE2 methodology which advocates a product-orientated approach to managing projects. This seems sensible to me.

However, in hindsight, looking back at projects I've been involved with, I've realised that some of these have only defined the product in suitable detail towards the end of the project. So for the first 75% of the project, the only thing known about the product is that it will be a publication of some kind. It is only then in the last 25% of the project where this gets defined in detail (for example, the publication will be 2 documents accompanied by 5 wall-sized posters).

This seems risky to me: since expectations are not being laid out until right towards the end of the product. If someone interpreted the publication to be a video, rather than documents, then we have an issue. On the other hand, I appreciate that not defining the product towards later in the project could be allowing more time for innovation and creativity.

My questions are:

Should a project always provide a view on the detailed specification of a product right from the beginning and manage changes to this specification using a change management process?

Or does it simply need to work out the right point in the process where detailed specifications are needed? If so, how do you understand where this point in the process is?

Answer 1

Short answer is no. In my own experience, this is the myth of requirements. I've never found a business or project team that can clearly articulate what they want at the beginning of a project. This gets worse if they've never done the kind of project that you're undertaking. Agile or a full-blown requirements package are just two different ways of managing this volatility. Both have pros and cons. It's more important to have a clear outcome (e.g., a 15-30 page printed book to teach 5th graders about the solar system) and manage expectations about when you'll have a better idea of what you want.

You can use progressive elaboration until clear idea of what you want is tied to product development. You can create customer personas, write out use cases, create prototypes, etc. until you have a better idea of what you're looking for. For example, if you produce a 30 page book with generic text (e.g., lorem ipsum), you might find that it's too much for a 5th grader to digest. Or you might realize that you'll be struggling for context. In PMBOK terms you should know what you want at the end of planning. You should be able to write it down. On a 12 month project, this could 9 of the 12 months.

As far as how you know when that is in a project, it's before you spend serious money. In the book example you could easily create prototypes with a printer and publishing software. Use generic pictures with watermarks and draft text. Print it out and get a god feel for it. Once you have a prototype you could reasonably put into the market, you're done. And that is your product description. Then the rest of the project is creating actual copy, buying the right photos, drafting a professional layout, etc.

Answer 2

Well the answer of course, depends... :)

If you are running a true Prince2 program (which falls in the purview of Traditional or Waterfall project management), then yes you should have the product fully defined before work begins. Note though that work does not begin at the start of the project. I don't know Prince2 in full detail, however it is very similar to PMI's PMBoK recommended process flow. In a traditional project you charter and define a project before any work is done. For some projects this can take a significant portion of the total project time. For example, compare how long it took to commission and plan the Freedom Tower in New York City.

If you are running an agile or lean project, then the answer can be summed up in the phrase "Just in Time". You do just enough planning to meet the needs of the current work or phase of the project. You don't define everything in complete detail because you recognize it will almost certainly change before you are done.

Answer 3

This is a general MBA answer on how a company manage project : one project is part of a wider strategy of development of a company. A company must be profitable to pay the fix and variable expenses every single month : salaries, electricity, heating system, etc. Some project are in the phase of growth, others in the phase of stability, others in the phase of decline. Some projects bring more money than others depending how advanced they are in their life time. Focusing on a product means you focus on the development of the product, not on the financing, the marketing and the distribution. You build a product that will satisfy the needs of the customer and meet the standards of your company. The strategies of development of a company and the tactics that will be employed vary with the environment in witch the company evolves : high competition, low competition, monopoly, etc. The manager of high level decides the strategy and push a product more than another.

Answer 4

Should a project always provide a view on the detailed specification of a product right from the beginning and manage changes to this specification using a change management process?

Depends on your organisations risk and change management approach.

Project management often involves giving perceived certainty to people by creating plans and specifications that indicate how you believe the future will occur based on now. Of course, things change, and then we have the choice of how we manage that change.

Some organisations will accept constant change as a part of life and will embrace it with methodologies such as the various flavours of Agile, or will use light and adaptable CM processes for PRINCE2 run projects.

Others will view all change as an imposition and put in place rigid change control procedures to make change feel like a punishment for not correctly predicting the future (can you tell I'm not a fan?).

Or does it simply need to work out the right point in the process where detailed specifications are needed?

This would be ideal, and the 'right time' will change from project to project depending on the level of risk and uncertainty and the appetite for them.

If so, how do you understand where this point in the process is?

When you know enough about the problem/solution to deliver value and (crucially) when the appetite is there within the business to accept the risk/uncertainty you're working with. The second one is the harder one to judge.