Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: development

Handling emotions in projects


Most people get emotionally attached to any creative work. While there is considerable element of science in breaking problems down, in software development, there is an equally significant element of creativity in resolving complex requirements. This is further heightened if you get to design the solution from ground up. I was part of such a solution – my role included business analysis and project management, but no development. However, I still felt significant ownership of the application, as I had contributed to ultimately what was delivered to the client and it had won awards in geospatial and port domains.

We had built the application with a view to making it modular enough to take individual functionality off and build another solution without having to start from first principles. Our lead developer had put it this way – a box of Legos – build what you will with it. We had tried to build this level of re-usability for some time and had finally looked like we had made a breakthrough. We were really excited with the prospect and the awards seemed a perfect vindication of our approach.

In a similar timeline our company became re-seller for a similar product. That product had a significantly larger development team behind it. As we provide implementation and customization on that product, it is becoming increasingly obvious that our original development would eventually be swallowed up by this product. One of the weaknesses of our development was a lack of configuration utility – which the new product addresses quite elegantly.

We are currently undertaking an exercise to upgrade the existing application to the latest Silverlight design patterns. We have had to think long and hard about whether that is indeed something that makes sense. What we have now decided is to produce a migration plan that would eventually merge the two together – hopefully leveraging best of both. This relies on design patterns of both being compatible. We’re in the process of undertaking a study to establish whether that is a realistic option.

From a business and technical point of view this makes good sense. We are simply not large enough sustain both and do justice to either. However, when you have your blood, sweat and tears invested in something, it is hard to let go. Mine was less than the developers … and it was no easier.

Is agile and PRINCE2 compatible?


My project management experience is in the field of software development. I deal daily with developers that espouse the value of agile development methodologies. Having come from a development background myself, I am skeptical about all that is said about agile. In saying that, I do see some benefits – especially the first principle of continuous and incremental delivery of software. However, a question arises … is PRINCE2 compatible with such methodologies, and vice versa.

For subsequent post on use of Agile and PRINCE2 together refer to this.

Let us quickly review the highlights of the agile manifesto

Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan.

Now let us consider the realities of bespoke software development. The project cycle starts with your organization given a set of requirements from a client and you having to provide an estimate to deliver to the requirements. As soon as you commit to a fixed price, scope and duration, there is effectively no room for agile. Depending on feedback, you cannot adjust the behaviour of the application – you will likely blow price, scope or duration – most likely all of them.

In PRINCE2, there is emphasis on the business case being continually evaluated to ensure the outcome is still desirable. PRINCE2 is also very process oriented – as evidenced by the 7 processes. It cannot therefore accept the first principle of agile development. There must be a process that states the requirements and any changes to the baselines and their impact. This can then be evaluated by the project board to evaluate whether the project is still desirable.

Working software over comprehensive documentation is a dangerous prospect in my opinion. Whenever there is squeeze on project time, documentation is usually the first casualty. This may produce working software at the time; however, it adds untold grief once it has been delivered. Anyone maintaining the system, whether it be your support team, the client’s IT team, or a third party will come to regret it. While I never enjoyed documentation as a developer, I learned to live with it as a necessity of quality work.

Responding to change is often trumpeted as a major gain of agile approach. Self organizing teams are put forward as a strong productivity source and one that can do away with a traditional project manager. These however do not take into account the inter-relationships between the projects, ability to analyze the impact of the changes to baseline, ability to hand over to an IT organization from project to Business As Usual (BAU).

One striking similarity between agile and PRINCE2 is how both treat the planning horizon. Both recognize that you can only plan so far in advance. Agile approaches do it by planning sprint content, PRINCE2 does it by planning by the stages. In that respect, there is some compatibility between the two. I see great value in utilizing some of the agile principles during the development phase of the project. Once I as a project manager assign the work package to the development team leader, if they use agile techniques to deliver within their tolerance levels, who am I to object?

PRINCE2 makes a distinction between the management products of a project and the specialized ones. Development of software here is a specialized product and therefore not specifically included in PRINCE2. Beyond the delivery stage of the project, I do not see agile meeting the requirements and expectations of executives and management to contract development services for a fixed fee.

In comparison, ITIL is probably more aligned to agile approach – especially during service operation stage. Once software is delivered into BAU, there is a continuous requirement to keep it running in an optimal mode, include additional functionality or evolve with the changing requirements of the organization. A programme of work can be created with continuous service improvement goals.

Tailoring is what makes or breaks your PRINCE2 project. Make sure you tailor it to suit your requirements. Pick from agile methodologies what you want and in which stages. Do not get locked into a specific one. When used, go more by the principles of agile manifesto, rather than a prescribed, particular method.

How long does software development really take?


I was reading some stats the other day … 85% of all software development projects fail to come in on budget or on time! That is a staggering and sobering statistic. In what other profession would there be such a low hit rate? How is it that so many bright people get it so wrong so often?

Software development is inherently a more risky proposition than many other projects. The reason a client is after bespoke development is because no such products exist in the market that adequately answers their problem. Some clients are better at expressing their requirements than others. In some cases they simply don’t know what they need. They just know that they need something. Read more of this post

%d bloggers like this: