you're reading...
Methodologies, Project Management, Uncategorized

Master Project Plans And Project Initiation Documents Are Important, But There Are Alternatives…

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.

An example PBS

An example PBS, although I would make the items actionable: “Engine Assembled”, “Transmission Finished” etc.

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.


8 thoughts on “Master Project Plans And Project Initiation Documents Are Important, But There Are Alternatives…

  1. It seems like you’re advocating a high level approach to analyzing a software system. However, let me see your post through the eyes of a developer. Your approach still doesn’t mitigate the issues that arise when using a highly agile software development methodology. Although PRINCE2 is really vague on how software should be made, it’s focus on delivering ‘product’ that in a sense are nothing but documents and do not pose any real value to the end user of your system (after a project is finished, a lot of PRINCE2’s documents are shelved, so I’m daring to say that the only value is during the project and then again not for those developing the system). My experience is that PRINCE2 project guidelines seem to fall short when developing a reactive, constantly adapting system and that it’s hard to reconcile with the fluidity that is inherent to an agile project. To me, the real value of PRINCE2 is keeping the bureaucracy out of the development team and forming a barrier between developers and other stakeholders. However, when it comes to how software should be built (ergo analysis, especially those readable and readily usable by technical developers) PRINCE2 should stay out of the way. IMHO, PRINCE2 should only be used in huge projects (50+ team) that have a lot of upper-level stakeholders. Below that threshold, it’s just overhead that is counterproductive at best.
    I do agree that an analysis should use ubiquitous language throughout the project and not repeat itself constantly.
    The sweet spot seems to be PRINCE2 managing high-level communication with a high level of abstraction (and only when such a level of abstraction is needed PRINCE2 seems to be a viable solution), and below that DDD and Agile should be able to manage the rest using skilled leads. A DDD approach ticks every box regarding your analysis requirements and is perfectly compatible with an agile way of creating software.

    Posted by Lieven Doclo | December 27, 2013, 22:30
    • Lieven, thanks for your reply. I seem to have the impression we both are marching against the same bureaucracy found in some organisations and are using different angles while coming up with distinctly named, yet similar outcomes. I am an advocate for reducing overhead in general and you seem to be as well whichever way or methodology you want to use; the end-result should always be that the “product” or sub-product is created according to expectations and quality criteria as fluidly as possible. While I use and came to love Agile’s approach to running (as opposed to planning) projects, I do not agree, or at the very least I have not seen all but the smallest of projects which are able to come up with a full-project estimate using it.

      I need to tell you fully wrong in one thing – please bear with me. To PRINCE2 a “product” is not only documentation – far, far from it! The most important products in a PRINCE2 project are the actual deliverables, the code you, as a developer, are writing! The article above tries to get rid of some of the unnecessary work one would do when incorrectly following a PRINCE2 project to the letter – indeed, another principle says “Tailor to Suit the Project’s Environment”, which means that you should adapt the methodology to what is best suited for the project.

      You are correct in other parts. PRINCE2 does fall short when developing reactive, constantly changing systems. In fact, it tries to offer a solution for it, while still allowing Agile to be used when actual work packages need to be delivered. To me, this “reactive, constantly changing system” is telling of the project’s organization and seems to indicate an incorrectly formed project team with the senior user being the prime culprit of the environment that this project runs in.

      _More_ of PRINCE2 should be used when running 50+ team projects, but it should never be limited to high-level tasks unless other approaches like Agile or DDD, or PMBoK or waterfall if you will are embedded ánd functional in the organization.

      Posted by Joris Verhuyck | December 27, 2013, 23:56
      • I understand your point, but PRINCE2 (and other project methodologies) seems to add a level of planning that is unrealistic to software projects. It’s impossible to make a full-project estimate for a software project and stating otherwise is a rightout lie to your client. There’s something called the cone of uncertainty, and the only reliable full-project estimate is the one you give the day before delivery. With agile projects, making your client aware of that concept almost entirely eliminates the need for full-project estimates.

        However, I strongly disagree that reactive, changing systems are a symptom of projects going awry. Most software projects, especially agile ones, are reactive and should be so for a very good reason. Like you can’t estimate software projects accurately it’s just the same for requirements or features. It’s like you’re saying that the senior user (product owner if you will) shouldn’t get as much input as he has now in agile projects. Which leads us to the mess we’re in right now: delivering software that the client once asked for, but has features he didn’t want now or lacks features he really needs.

        Like you’re describing it, PRINCE2 is nearly impossible to implement when dealing with an environment that embraces change together with the customer. In that sense I can’t see PRINCE2 working in a continuous deployment/devops scenario (which encompasses just about every startup/large web software project out there nowadays), as PRINCE2 doesn’t support that kind of speed and agility. And if it did, it would definately fall behind and therefor be reduced to a documentation framework for high-level execs. The product may not only be documentation, but PRINCE2 does not dictate how code should be delivered, only that it should be delivered. In that sense, during development, PRINCE2 has no added value whatsoever and can only work counterproductive if it tries to interfere (or ‘blend in’).

        It’s like you said, when agile and DDD are embedded in an organisation (and IMHO every software company worth it’s name should use at least the first if not both) PRINCE2 becomes nothing more than a high-level documentation framework (and an expensive one at that). Which leaves only the waterfall projects as an applicable field for PRINCE2 and PMBoK and let’s face it, they are a dying race (except for maybe government projects).

        My point is: if countless years of classic software development have learned us one thing, it is that it cannot be forced in formal methodologies (the road is littered with the corpses of projects that tried). It’s like trying to fit a square peg in a round hole. While I recognize the need for a documentation framework for high-level execs who don’t need the nitty-gritty details about a project, I don’t see the need (anymore) for formal methodologies like PRINCE2 or PMBoK when using a truly agile approach.

        Posted by Lieven Doclo | December 28, 2013, 01:06
      • Lieven, like you, I understand what you are saying, as I understand your frustration with how some (software) projects are running / have been run. Solely putting the main blame of these projects running wrong on PRINCE2 (or other project methodologies) and proposing DDD and Agile as the end-all solution to whichever problems you are running into also is an outright lie to you client.

        PRINCE2 does not preach to have full-project estimates right at the start, quite on the contrary, another one of its principles says “Manage by Stages”. Like Agile, PRINCE2 is prepared to run projects in a changing environment – although it would not easily allow last-minute changes to agreed course of action – although that can be taken with a grain of salt as well, since, as long as your PRINCE2 PM can move project scope “within agreed tolerances” for a certain stage, he is free to do so (also falling under a principle btw: “manage by exception”).

        I fully agree with your cone of uncertainty (or planning horizon) remark and clients should be informed that creating a detailed planning going more than 2-3 months in the future, is completely impossible. As a PRINCE2 PM, I am as unable to tell what person X on my team will be doing on day Y 3-4 months, let alone a year in the future, much like you.

        I’m saying that the senior user or product owner should have a very large say in the day to day proceedings of any which project. If a senior user does not know what he wants / does not have a “vision” of where to go to or if he / she is unable to “share” that vision with the project team, bot PRINCE2, as well as DDD/Agile projects will veer off-track. Like you, I embrace change together with the customer, but PRINCE2 puts limits to it over the course of a running phase. I mean, imagine you had your sprint planned (a concept which is fully compatible with PRINCE2 mind) and in the latter half of that sprint, your product owner completely deviates from what has been discussed in your sprint planning meeting, an Agile project will have much the same problem as a PRINCE2 one. The difference is that PRINCE2 has the controls and processes in place to react to that change (by using Exception Reports and Exception Plans), while in Agile, you just forget the sprint and plan a new one – if I’m not mistaking.

        When I am starting up or initiating projects, I will be very mindful that some kind of “product” is created to identify the domains (or concepts) which the project is touching upon. To me, identification of these domains is of utmost importance in order to grasp what the project is about, to define its scope and to level the playing field for successful delivery of the project’s outcome.

        Lastly, yes, PRINCE2 offers a complete solution (in tandem with Agile development for example). It defines the management products for high-level execs, as it does for lower-level product delivery. How lower-level product delivery is managed and tracked on a daily basis, might indeed be done in an Agile way – in fact, I fully support that. So, as far as I am concerned PRINCE2 or PMBoK are project management methodologies, while the Agile solutions are development methodologies – both are needed, both can very happily co-exist.

        (strange that we are discussing PRINCE2’s notorious danger for overhead under an article, questioning one of its most known documents and which starts with a reference to PRINCE2 alleged inability to respond to changes! ;))

        Posted by Joris Verhuyck | December 28, 2013, 11:52
  2. Then would you agree that in an agile environment, let’s say a scrum environment, that PRINCE2 has a more supportive role than a leading role? I never said that DDD and Agile is the silver bullet to software projects, but I have seen too many PRINCE2 PM’s shouting that their approach will save a project or make a project succesful.

    To me, and to a client I think, actually delivering working software is the most important deliverable of the project, not the PID, exception reports, exception plans or any of the documents produced by PRINCE2. These only get shelved at best. The vast majority of the time and work invested in software development projects goes to actual coding. So in that context, the delivering a work package, the least documented part of PRINCE2, is more important than any of the other parts of PRINCE2. Don’t get me wrong, these are important too, but IMHO a project can live without having to make an exception report for changes while it cannot live without delivering code.

    The fact remains that in agile environments (and especially in extremely agile use-cases such as continuous deployment scenarios) incorporating project management methodologies will remain a hard thing to do. Classic project management methodologies like PMBoK or PRINCE2 are just not flexible enough to adhere to the agile principles. Unless in the case of PRINCE2 you make a stage the equivalent of a sprint, but in that case PRINCE2 is reduced to a thin documentation wrapper over agile principles and can be considered as (perhaps necessary) overhead.

    If you can think up of a project management methodology that in no way interferes with agile principles, I’d be more than happy to promote it. But in the last 6 years I’ve seen both PRINCE2 and PMBoK fail over and over again, adding a level of rigidity to an agile team. The end result was always the same: mountains of paperwork and not a single working coded module.

    As a developer and Scrum Master I firmly believe that code should come before any other deliverable. It’s the only thing that counts for an end-user. Any PM methodology that supports that belief I will support firmly and just as vigorously like my replies here. Maybe that’s PRINCE2, but I’ve yet to see the incarnation of such a variant.

    I’d be more than happy to discuss this over a beer :).

    Posted by Lieven Doclo | December 29, 2013, 00:50
    • Yes I would agree there. Agile and PRINCE2 are complementary methodologies. They both serve a different purpose. It’s your point of reference which decides which one of both is supportive or leading. Seen from a PM point of view, I would argue that PRINCE2 is leading and Agile supportive. Taking a developer’s approach that would indeed be the other way around.

      I have seen way too many projects fail as well and again, I think it is not the methodologies by themselves which are to blame, rather the PM’s or organization’s interpretation of them. Not too long ago I was working at a certain company, which I am not going to name here and it installed a new method for their ICT projects. The program must have cost them hundreds of thousands of euro to have implemented, given the lively documents they created over the years. While it was indeed based on PRINCE2, it tried to implement it by the letter, as well as overdo some aspects of it. The result was a terrific work of academic level, but wholly unsuited to deliver projects with. The result was that each of the different pm requirements: establish controls, quality processes (i.e. testing in their opinion), functional and technical analyses and so on, each had their own subject matter expert who actually was able to comment as well as destroy each possible deliverable a project needs. That goes so far against a good project’s organization it is plain baffling it got installed at all.

      Now, as a PM, you should have the authority to control these aspects yourself – I was only team lead there, or “project leader”, a role which was not even mentioned in all these documents, as correctly noted by someone in the team, and I was battling with the PM to please address some of the many many concerns I had. So, as a PM, you should go against such a crippling interpretation and implementation and if you fail to do so, you’re not a very good PM at all.

      I don’t entirely agree with you saying that the vast majority of time and work invested in a project goes to coding, but don’t get me wrong: without code, you’re not going anywhere either of course! I do say that another very large and extremely important part goes to handling the change the project brings. These changes, both _before_ coding by consulting senior and key users about what they want, as well as _after_ coding by training all the end-users and by managing a human’s reluctance to change, also take up a fairly huge chunk of project effort, be it a chunk which is being kept under the radar in a lot of projects, since “business effort” is not always estimated as fine-grainedly as IT effort.

      I can’t think up a methodology which in no way interferes with agile principles, if agile principles are solely about delivering code without documentation, but they aren’t. They value code without documentation more than they do the opposite, so tension between them, Agile and PRINCE2/PMBoK is going to remain there, but you can, and a company should marry the two. You use (some or all of) PRINCE2 to create an overall project organization and chose Agile to manage actual product delivery for all but the smallest projects, where a completely Agile approach probably is good enough.

      Always in for beers here! 😉

      Posted by Joris Verhuyck | December 29, 2013, 15:18
  3. Good conversation / post.

    Re Agile development I find it’s able to mask failed projects quite well, with no real plan and continuous development I’ve seen many a project get shelved without proper close out and accountability, I’m yet to study the Agile method in detail so I can’t say if that’s just the teams I’ve witnessed or a weakness in the method. Furthermore projects farmed out to a 3rd party must have controls or the PM will be change-ordered out of a job.

    Re the problem that had me post my question on the last article is the sheer volume of relatively simple projects I’m to manage while at the same time maintain audit-able documentation. I’ve decided that one yearly set of logs and registers is the best option using a tool that will allow me to pull reports on all items related to a single project. I’m now trying to tailor the Product Breakdown Structure, Product Flow Diagram and Product descriptions into something that makes sense; I believe I’ll try and create a ‘product library’ that I can reuse. I’ll know in a few months if it worked..

    Posted by Ben Pappin (@Pappi23) | January 6, 2014, 23:36
  4. Re your remark on agile projects: if it’s able to mask failure easily, you either are doing it wrong (no demo’s, no retrospectives, no planning meetings with the product owner) or you have a product owner who doesn’t care about the project. In both cases no amount of PM methodology wizardry will help you out.

    The primary weakness of agile methodologies like Scrum or XP is that if it’s only implemented to a certain degree, projects will still fail. With agile, you go all the way or you don’t go at all. Projects that follow agile principles to the fullest are extremely transparent and visible, therefor failures are painfully easy to spot (which, by the way, is one of the major causes of resistance to adopting an agile methodology). However, most companies that want to adopt an agile methodology make the mistake of saying ‘well, we’ll adopt this principle for starters’ and after a month or so see no visible positive change and at that point they blame the methodology. When agile is implemented incorrectly or incompletely, it has the potential to do a lot of damage. But in that case, the method isn’t to blame but rather those trying to implement it.

    To counter your statement, it’s equally easy to mask a failing project with PRINCE2 or other formal methods. PRINCE2 is perceived as highly document-based and as long as you keep delivering those, you can postpone showing you failures for a very long time, until you actually need to show your finished product.

    Posted by Lieven Doclo | January 11, 2014, 13:07

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: