A whole while ago, I posted an article calling in question the importance and necessity of a Master Project Plan or Project Initiation Document and I defended that some times they cripple an organisation’s agility to respond to changes quickly, all while creating quite some overhead to running projects.
It was when Ben Pappin (@pappi23) commented on it that I realized that I indeed critiqued the necessity of what often is referred to as a PID, but that I have not brought up solutions. I was asked the very correct question that, when you decide to do away with lively documents, you surely need a program in place to deal with the repetitive parts of them and that is indeed correct…
I’ll use PRINCE2’s terminology to discuss a possible solution to repetitiveness. So, in order to understand the rest of this post, it is important to grasp PRINCE2’s principle to “Focus on Products“. What does that mean?
To PRINCE2 almost all that is created during the lifecycle of a project is called a product. Thus, products are the deliverables to be created in order to successfully complete the project. Should your project be in construction of buildings, some products are likely to be: “flatten terrain”, “bore foundation holes”, “lay foundation”, “lay groundplate”, “build walls”, “build roof”, “design electrical wiring”, “lay electrical wiring” and so on. Each of these products come with their own set of quality criteria, are sometimes executed by different persons from one product to another and are validated by a third group still. They all are a part of the complete Project Product – the finished building in the example here, which sits atop the Product Breakdown Structure as the ultimate project’s goal.
There is another kind of products in PRINCE2 though – which should also form part of the PBS, namely the (project) management products which need to be created. Basically these are the 26 different documents PRINCE2 describe in order to successfully manage the project from day to day, week to week… The “Daily Log” is an example, the “Issue Register”, the “Exception Report” (should you have any), the “Plan” and of course the “Project Product Description”, as well as the “Product Descriptions”. It is the latter which are core to using a modular and non-repetitive approach!
Whether your specific project needs all 26 management products, is an entirely other subject, which I am not going to discuss here. Let’s focus on the product descriptions…
The theory indeed says that for every identified product in the PBS a product description needs to be created and approved. They all form part of the Project Initiation Documentation. Note that PRINCE2 specifically uses the word “documentation” as opposed to “document” – I lost count of how many times I have seen that incorrectly written about or spoken of. But what if a lot of your identified products are similar in nature, but different in content? You’ll need to identify each product by itself and create a product description for them, but, given their similarity in nature they quickly seem to be repeating themselves in some or even all parts of the product description’s sections. I take it that an example will explain things more easily…
Say that you are building a new web application. Each of the screens your application will be using need to be analysed before it is built, this means that for each screen you will have an “analysis” product, as well as a product description detailing the contents and behaviour of the screen itself. The latter product description is the result of its analysis, but it is the former product descriptions which are repetitive, since they are similar in nature. Just think about the quality criteria for an analysis which are mentioned in the PBS. Each and every analysis need to adhere to some criteria. An analysis needs to be:
- Clear and concise
- Readable, understandable and approved by technical persons
- Not contradicting other analyses
- In English, French, German, Dutch, Japanese… (pick one!)
- Using UML, BPMN or whatever notation
- Clearly explain the product’s relation to the other products
- State which dependencies and constraints the product has
An analysis for a landing page needs to follow these quality criteria, as does an analysis for a server or an analysis for an interface to other applications. It is quite safe to suppose that these criteria will remain constant from one analysis document to the other, so are we, according to theory, going to recreate the same document over and over again to only change the title of it?
I would strongly advise against it. The work is frustrating, doesn’t add value to the project and basically is a waste of time should you decide to do so. The solution is to create a library of generic or standard product descriptions which you can refer to when you need it. You could say that in your organization each analysis product needs to follow the corporate analysis’ product description and be done with it. Instead of readdressing the same thing over and over again and creating PID going for 100’s of pages, you’d reduce them and point all generic products to the generic product descriptions instead and you’re done with repetitiveness!
I hope this helps some, if it does, feel free to leave a comment. If it doesn’t, then ask away.