Project Management in Practice

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

Category Archives: Agile

How does organisational growth impact project delivery?

Delivering projects is more than simply tasks undertaken to get something out of the door. Inevitably, how a project is delivered is dictated by the culture of the organisation. I work for a niche technology solution provider that has undergone nearly four-fold expansion since I joined six years ago. I have been thinking how that has changed our project delivery. Many of the analogies I draw will be familiar to you if you have read Frederick P Books Jr, the father of IBM System/360.

As a small company, we worked on small projects – mostly using one or two resources. Because of the size of work we could take in, there was a natural limit to risk we were exposed to. It is easy to communicate between two or three people by simply sitting next to each other. Even informal communication is sufficient to set goals, share designs, report progress and quality control each others’ work. Because the work packets are small, it is also easier to slot them in based on project timeline commitments. We managed to get a phenomenal productivity out of our staff.

As the company started growing, the work packets started getting larger. We were able to take on more complex work. Goals that a project manager could explain to two developers, now need considerable documentation. He cannot now sit next to all the team and fill in the gaps if something comes to light. As growth continued, there was need for more project managers. This creates more challenges, as now all the project managers have to align their processes to ensure projects are delivered in a uniform way. Slowly, but surely, the productivity achieved in the early days becomes difficult to sustain.

The staff we have are of exceptional calibre. So why the impact on productivity? The key here is the the overhead of communication. The original scenario I described is what Brooks calls the duo working out of a garage producing software that far exceeds big teams. However, there is a certain size of software you can produce with that capacity. In order to deliver something more complex with the two same developers, it will take so long it will not be worth pursuing. The only answer here is to add more people. As soon as you do that, it creates the productivity issues I talked about previously.

A simple mathematics shows the impact. The communication channels in your project team is n(n-1)/2. In a team of 2, there is only a single line of communication. Team of 3, makes it 3, 4 makes it 6. As you can see, More people you want to herd to the same goal, your communication effort multiplies exponentially. Military works by asking no questions. So one may ask why not follow that model. Most of your development team are usually from the opposite end of the IQ spectrum to that of your privates. Persuasion is your best ally here.

This clearly shows that more complex the delivery, and more people are required, software development itself becomes less of the overall effort. Ensuring the team works well, everyone knows what they are required to achieve, outputs are tested for their fit for purpose and efforts are targeted correctly to achieve the goal that has been set out requires considerable dedication.

Many a time reaction from management or clients is to throw more resource at it and expect output to increase in a linear fashion to the number of resources added. That may be achievable in fruit picking, or office cleaning, not in software development. It also does not take into account some tasks take a certain duration. No amount of resources will deliver an early output. I love Brooks’ analogy here … Bearing of a child takes nine months, no matter how many women are assigned.

Have you been growing recently? I would love to hear your experience.

Is Agile for me?

If you talk to any project team, you will find varying range of opinions regarding the best methodology for development – all very passionately putting their points of view across. Barring the occasional accident, most of these teams have given considerable thought to what is most applicable to them and have followed that course. When each of them argue in favor of a different methodology, it is well founded in facts. However, the one thing that is missed in all these discussions is that the challenges facing all the different teams are not the same. Let us consider various scenarios.

Follow this scenario … an organization realizes the need for a new system. They go through an internal requirements gathering process and invite tenders for the system, to be implemented by a certain date. You are a professional services organization. You are required to estimate the effort required to design and implement the system. In your response, you have to provide a price, as that would undoubtably be one of the selection criteria. You happen to win the tender. What is your status? You are now locked into a fixed deliverable to the client, to be completed by a date within a cost you have specified. Is there any room for agility? When you think about the triangle of constraints, effectively you can move none.

You can legitimately ask why not estimate to do the work following Agile principles, that would solve this dilemma. Let us then review how business is done in the real world. For all of us IT professionals that like to think we’re God’s gift to mankind :o), the reality is that we’re a support cast in most organizations, that only utilize IT as a means to achieving their business goals. In business, everything is driven by supply and demand. Think of it this way … if you bought something from a store, you may be able to take it back and get something else that is in a slightly different color, or size. However, if you ordered something custom to be made, and then changed your mind on the size, would you expect that to be accommodated? This is the difference between a product sale and custom work. Software development is no different.

When you are developing a product, or are in a development or support team within the organization, you have a steady commitment to resources. You have the ability to select your sprint schedule. Your costs are also therefore fixed. You have some leeway on scope. In such scenarios the organization has already accepted the cost of this continued effort and therefore scrutiny on the resources (and by extension cost) is not the same. The scrutiny is likely to be more along the lines of value for money … is the overhead we have agreed to getting us the improvements (or new functionalities if it is a product development) we’re after.

Custom development is an entirely different beast. Here uncertainty reigns. Most likely reason the organization is getting you to do the project is they do not have the resources or capability to do it themselves. At the same time many of the users will also not have the understanding of what is possible to achieve. In such scenarios you will end up spending significant effort in communicating possibilities and success criteria for your work to be accepted. Encouraging change of requirements, even at late stages like Agile methodologies will ensure you never come in on budget or are forever locked into a change control battle.

The second key when considering using Agile methodologies is the likely size of the project team. In essence the Agile teams are self organizing teams that work based on a given set of requirements and set their own schedule. The emphasis is on responding to change over following a plan. This works really well and reduces overheads. However, this is only true for a small team. When the team size goes to beyond six or seven, this becomes more and more difficult. Adding each new team member adds many new lines of communication necessary to keep this self-organization working efficiently. Bigger the team lesser the chance of success using Agile methodologies.

If you have been landed with an Agile project because no-one knows the requirements, think again. That is a guarantee for chaos. Agile is not a substitute for requirements gathering. In fact, Agile requires a continued emphasis on requirements through product backlogs and user stories. There is a constant requirement to refine user stories, even for items that do not make it to the current sprint. Many a time customers will not object to time spent writing code and testing it. They will object to this continuous refinement and management efforts. Before you jump in, consider if your client is inclined this way.

Does this mean that you cannot use Agile principles at all in some of these scenarios? No, that is not necessarily the case. You can use Agile principles in your teams, but will most likely struggle to run the entire project using Agile practices. You will need something overarching to ensure adequate control and communication. Agile is best suited for product development and in-house support teams.

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: