Project Management in Practice

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

Tag Archives: Agile software development

How do you remove dependency on individuals?


One of the key challenges faced by a Project Manager is to ensure their project is not beholden to an individual for its success or failure. This is especially the case longer the project is in motion. This challenge is faced by the project teams more often than it is acknowledged.

Consider what happens if one of the key staff want to take a vacation, they fall ill or has a family issue, decide to leave altogether or the Project Manager wants to take some time off?

Project Managers are inherently risk averse. There is a tendency to utilize people they have previously worked with and to try and maximize their productivity. It is also against project management ethos to spend time doing this that does not progress your project forward and lead to ticking off a specified outcome. This caution is well served, until the first sign of resource shuffle.

How does the Project Manager prevent a calamitous turn of events? One of the Agile software development methodologies has a very interesting approach. Extreme Programming (XP) insists two developers work together to deliver tasks assigned to them. XP claims improved quality delivery and resulting lesser cost of lifetime delivery as the reasons for the approach. However, this also immediately lessens the reliance on one particular developer. As well as efficiency gains, the approach immediately provides a level of   knowledge sharing.

When assimilating a new member in the project team, one of the key challenges challenges is to get the same productivity from the new member as was the case with someone that had been an integral part of the project. This difficulty is usually in the form of knowledge the previous team member had picked up that is not documented anywhere. Even if the new resource is equally as competent as the one they are replacing, they still may not know the approaches that had already been tried and discarded. The only way to ensure the new resource does not waste time by trying the discarded approaches is to have good documentation of tasks assigned and progress on those.

You reap what you sow. If you plan for and encourage a wider team participation in your project, you will be in less risk of getting stuck when something unforeseen happens with your resources. In many cases, the additional effort required is a difficult argument to make. I find it is easiest to get my message across by quantifying the impact in terms of schedule delay or cost to project.

Can you manage all projects through PRINCE2 or Agile?


Christchurch Quake Map

I have been an avid advocate for PRINCE2 as the project management methodology with agile practices incorporated to deliver the specialised products of the project (software, hardware, service etc.). I have recently been working with the Canterbury Earthquake Recovery Authority (CERA) to provide geospatial support required for evidence based decision making as it charts a course for a difficult journey to bring Christchurch city and the Canterbury region as a whole back on its feet. This has led me to ask if PRINCE2 or agile methodologies can be used to deliver a project of this nature.

Let us review the fundamental tenets of the two methodologies. The key to PRINCE2 is the management structure of the organisation. Here I refer to the project management structure with the Senior User representatives as the organisation, rather than the entity which the project is being conducted for. In a state of emergency or its aftermath, most of the staff in CERA are seconded from other government agencies. They are so busy keeping the ‘lights on’ in their existing roles, having an effective Senior User group becomes virtually impossible.

Agile too requires participation of the stakeholders. It is assumed the users have the ability to help plan, prioritise the product backlog and provide timely feedback of stories in progress. Many of the staff simply do not have the time luxury to do justice to that. They are not only involved in the recovery of the region, but also their individual lives. Priorities also change from day to day. While some may argue this is ideal for agile delivery, there is a limit to agility. The fine line between agility and chaos is crossed more often than not.

A factor that has impact on both methodologies is the fact that most data owners are outside CERA and the service provider. Data is owned by the city and regional regulatory authorities, engineering companies assessing the damage. While there are some powers that CERA can use to ensure data requests, it becomes a futile exercise brandishing big guns to achieve small gains. What is required is more of people (or organisation) management to ensure high morale and a sense of accomplishment together.

The key to success here is programme management ahead of time. It is key to have a Spatial Data Infrastructure (SDI) where the various agencies can find and harvest data. Encouragement needs to be provided to ensure participation is seen as beneficial to all parties. There is always apprehension about data quality and the likelihood of others discovering those errors. Rather than having those as barriers to participation, it needs to be seen as opportunities to improve data quality through feedback.

When not in emergency, it may seem there is little benefit to undertaking such a programme. Benefits of the programme needs to be judged not on what it is achieving in the existing business processes of the organisations, rather the opportunity costs of not having knowledge or access to the data to undertake more accurate analysis or create additional products. In times of emergency this becomes the information backbone of recovery efforts and policy decision making. This has to be managed as a programme, not a project.

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: