Project Management in Practice

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

Tag Archives: Information Technology Infrastructure Library

What methodology do I use?

There are a plethora of project management methodologies out there. Each have their own strengths and weaknesses. How do we choose what is right for our environment? I am presenting to a peer forum of Project Managers. This is a draft of my thoughts. The full blog post can be read here.

Prince2 ITIL Agile … what is best for me?

View more PowerPoint from Shoaib Ahmed

What methodologies do not solve

Organizations evolve through various phases in their existence. Good organizations have a continuous focus on how they do business and strive for improvement. One of the most common realizations organizations come to is the need to utilize standard methods and best practices in order to ensure higher quality outputs from its staff. While this is a correct realization, implementing these is where a lot of organizations go wrong. Let us explore.

A lot of organizations, when they realize the need for standard methods and best practices will send staff away to courses. In the case of project management, they may get sent away to do a certification in PRINCE2, PMP or Agile, for service delivery management, they may get sent out to get certified in ITIL. You get the drift. What I see many a time is this is sufficient and the organization will suddenly become followers of best practice. There is then wide-spread surprise and the reality turns out to be something different. Why then despite the obvious intent, do many of these initiatives fail?

The first thing everyone needs to appreciate is no methodology can ever cover all the practical scenarios an organization will face. Best practices are just that … best practices. Knowing the theory is all well and good. Reading a particular scenario and understanding it to answer questions is different than what someone will face in their regular role. There is no benefit of hindsight. In many situations, you have to make a decision on the facts at hand, which may not be full. Later, you may be required to account for those decisions to someone with benefit of hindsight. This requires not only understanding of methodology, but also an appreciation of how to apply it to various scenarios.

If you have studied information systems, one of the first things they teach is the theory of normalization. However, what they do not necessarily teach is in certain scenario, it is a more efficient to de-normalize parts of the system. For non-IT readers, I can equate this to child rearing. The best practice is to always keep a routine and not deviate from that, so you set clear boundaries of expectations. However, every now and then it is good to indulge your children slightly to build a warm reciprocal relationship with them. There is always fine balance here that requires judgement and constant review. What is best practice may not always be a good practice in certain scenarios.

I have seen selection of methodologies as a response to a project disaster or an attempt to cover gaps identified in a procurement process like responding to a Request for Proposal. That usually leads to selection of methodology from a very narrow focus. There is also a huge difference between selecting a methodology and adopting a methodology. Selecting one is on the easy end of the spectrum. Once selected, the organization may send some people to training. When these people come back into the organizations with new ideas, they challenge the established way of doing business. This challenge may go beyond what management had intended to address when it embarked on the process. Unless there is a willingness from management to re-examine the practices, then there is little or no value in selecting a methodology.

Methodologies do not solve any business problems. It is the people that absorb ideas, question existing practices, design improved processes appropriate to the organization and have the will to see it through that make the difference.

PRINCE2, ITIL, Agile … can I have the best of all?

There is a lot of discussion about what the best methodology is to adopt for an organisation. As soon as the discussion moves in that direction, it moves away from realities of any Software Development Life Cycle (SDLC). Projects simply do not mushroom out of thin air. Something causes a realisation in the organisation that moves them to  mobilize and start a project. The project than needs monitoring and control to bring the desired transformation in the organisation. Read more of this post

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.

%d bloggers like this: