Project Management in Practice

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

Tag Archives: Management

Project management lessons learned from a vacation


After nearly a two month hiatus in blog posts, it is time to jump back on the horse. In that time, I have spent five weeks on vacation and either side of it two and a bit weeks in doing handover and picking the work back again. I thought it would be useful to share lessons I learned from this exercise.

Project management lessons learned from a vacation

The Preparation

This is the most stressful part of going on a long vacation. I had worried about projects suffering in my absence due to lack of control or guidance. Clarity in decision making based on experience is a key skill of a Project Manager. As many Project Managers do, I still carry my cell phone during short holidays. There is always a fallback if the wheels start to wobble. On such a prolonged vacation overseas I was not about to entertain being on call. I therefore asked for a short term stand-in for my role. I involved in various projects during a two week period to ensure he had sufficient background in the processes we followed and status of the projects to carry them through for five weeks.

The Vacation

This was the first vacation of this length I had taken in nearly five years. Having done the legwork with my stand-in, I was surprisingly relaxed during the holiday. I cannot put my hand on heart and say I never worried. Anyone with a level of responsibility will from time to time worry about events beyond their control that they cannot steer their team through. Most of the incumbent project teams and support teams – sales and management – were still there. Needless to say I enjoyed my time off in the knowledge that with the handover I gave and the available support structure the risk of total cock-up was relatively low.

After the Vacation

On my return I was pleased to see three quarters of the activities were done as I had wanted. Some were left for my return that required a level of experience or authority to carry out. While there were some thing done slightly differently, I can accept that as best effort choices based on information at hand. One particular area was done better than I had expected – breaking development work packages into short sprints. The week following the vacation was spent trying to get back to the rhythm of work and getting a handover.

What the team learned

The team understood the consideration, communication and time it takes to make decisions on project related matters. Many a time some of these challenges are nto visible to the project team (or for management for that matter) and cannot be readily appreciated. The fact that quite a few decisions were deferred and a lot of the decisions required quite a bit of internal discussion gave them an appreciation of challenges I deal with on a daily manner.

What I learned

The biggest learning on my part is that I need to worry less about thing going wrong in my absence. My team is made up of some very capable people and are able to provide good guidance on how projects should be executed. I will probably look to see how I can take advantage of that to get some of them to provide more leadership. From a personal point of view, the vacation has enabled me to recharge my batteries and come back with renewed energy. I will also look to ensure my team gets the same opportunity.

It is good to be back. Keen to hear your learnings from similar experiences.

Image Credit: NewHotelsUs.Com

Understanding the change appetite in organizations


Projects are temporary activities that allow the organization to implement a business change. The word change is the operative word. A Project Manager is responsible for delivering the outputs that will enable the desired business change to take place – within the tolerances afforded to him in the areas of – timeline, cost, scope, quality, risk and benefits. Are all organizations equal in their ability to accept change? How does it impact project management?

Not all changes are equal. Consider a change related to upgrading a software used by an organization, to changes in business process, to slashing staff numbers to fit into a new operating model. These are all changes with various degrees of disruption. Higher the disruption, more attention needs to be paid to the change appetite. The Project Manager will not always be able to work within the change appetite in the organization. It is therefore legitimate to ask whether there is benefit in trying to understand the change appetite.

The reason to focus on the change appetite is to identify and quantify your project risks and having some guidance on what appropriate risk actions are. For small changes you may want to accept the risk and move ahead. For more disruptive changes – in the example of slashing staff numbers – you need to consider not only the actions that the project will need to undertake to achieve the objective, but also disbenefits associated with those – uncertainty, resulting productivity loss, departure of staff you had intended to keep etc.

More disruptive the change, the likelihood it is done less often and more chances of people losing nerve in the midst of the project. You need to ensure higher commitment from management as a result. If the project is about developing a new product to be first in market, ensure you have the right level of buy in internally. It is easy to get derailed as many in the organization may not have the same appetite for not only the change – but also the risk, cost or benefit. As you progress you need to ensure you measure viability using a constant yardstick.

As you undertake the project many in the organization will respond … why do we need this, or we’ve always done it this way and it has worked, why change … and many such questions. Remember there is also an opportunity cost to doing nothing. Ideally vision for the future state comes from the leadership in the organization. You will find top-down communication approaches will not always work as well as management assume. This is where understanding the change appetite can play into your hands. Arm your project team with the vision of what you are delivering. Lines of communication cannot be controlled. If the project team has the same vision, they are able to generate a level of understanding within the organization through their daily interaction with the business at large.

You will need to manage your project executive / sponsor effectively. Sponsors usually come from the business background and are usually less aware of projects and change management. Many are happy to step up with the additional responsibility and are capable of taking the organization on the journey. Equal number if not more are not able to do that. Encourage those to up skill in the role of sponsoring the projects if you think that is necessary. While you want maximum clout from your sponsor, be wary of picking someone who does not have enough time to do justice to the role. Pick the CEO at your peril 🙂

Change = Resistance = Risk. By understanding the risk appetite of the organization you are able to quantify risks and action plans, which gives you a higher chance of success.

Image Credit: Matt Davies (Journal News)

PMBOK or PRINCE2 … which one is better?


I often see debates on project management forums on LinkedIn, blogs and even at the water cooler around the office regarding what project management methodology is best. I have often wondered about the wisdom of such discussions. The two that are always compared are PMBOK (Project Management Body of Knowledge) and PRINCE2 (Projects in Controlled Environments Version 2 – 2009). One such discussion with a fellow professional led me to have a little bit of a think.

PMBOK Process Model – Credit: PMI

I will declare my hand at the outset. I have squarely gone for certification route through the Cabinet Office products for project, programme and service management (PRINCE2, MSP and ITIL). This is not necessarily because I was convinced these were the best frameworks, but my assessment of what the market around me considered more valuable. With the Australasian market following that of the United Kingdom and Europe, it made more sense for me to pursue this line, than the PMBOK based certifications from the Project Management Institute (PMI) in PMP and PgMP.

PRINCE2 Process Model – Credit: ILX

Genesis of PMBOK is in the engineering sector in North America. I can see that has led to significant emphasis on the tools and techniques of how to manage projects. I find it has excellent guidance in what it calls the knowledge areas. For example, it provides techniques for monitoring and controlling projects through Earned Value Analysis (EVA), estimation through the Program Evaluation and Review Technique (PERT) analysis. It elaborates on Precedence Diagramming Method (PDM) to identify sequencing and various lag options. It has tools and techniques for scheduling using Schedule Network Analysis, Critical Path and Critical Chain, discusses Resource Levelling and What-if Scenario Analysis. Tools and techniques is where PMBOK has it all over PRINCE2, which goes very little into the skills required to be a project manager.

PRINCE2 began with a desire to control capital IT projects in the United Kingdom. Interestingly, a methodology that began in such a technical sphere has very little in the form of guidance through tools and techniques. PRINCE2 is very strong on project governance. Its strength is in the focus on the continued business justification through a living Business Case. In managing by exceptions, it removes the temptation for death by project reports, but at the same time provides a mechanism for escalating when necessary. In managing by stages, it builds in regular reviews of whether the business case the project is trying to deliver to be still valid. The biggest outcome of this is the assertion that a project unlikely to deliver to business case is better cancelled than meandering along. Project structure and principles also ensure projects are delivering to strategic initiatives of the organisation.

I have previously posted about the challenge in implementing PRINCE2 as the project framework for supplier organisations. I have used the principles rather than exact implementation as described in the text. It is much easier to take the PMBOK tools and techniques and implement directly into your projects in a supplier context. PRINCE2 however does a better job of risk identification and management techniques with the various response options and planning. There are also pros and cons about the accreditation methods. PRINCE2 is often criticised for allowing potential non-practitioners to get certified because of its examination only method. In order to get a PMP accreditation, you have to go through a significant effort to prove hours under the belt. That is a good idea. But you have to accumulate Professional Development Units (PDU) to stay current. I have seen plenty of mickey mouse outfits dispensing PDUs like confetti to have any meaning to these.

When I consider all of this, it appears a futile argument from those in either camp. In my view the best option is to use PRINCE2 to understand “how” to run the project and PMBOK for guidance on “what” to do in the specific scenarios. The question is not one of PMBOK or PRINCE2, but how to use both in your projects.

How do I tailor PRINCE2 to deliver IT projects?


I had been reflecting on a comment Geoff Rankins made at a previous PRINCE2 User Group Meeting regarding most IT projects not delivering the stated benefits. I have concluded that I agree. Most of the business cases for these projects are put up by the IT departments and vastly overstate the benefits to get those approved. Some even go to the extent of hiding the cost in operational budgets, so they don’t have to put up a business case in the first place! The consequence is those benefits can never really be measured or met. IT is not the core business of most organisations. I don’t think many of us in the IT profession have quite grasped it. It exists to provide an answer to a business question. Therefore, IT should not be putting up business cases. Their role should be to be the subject matter experts that advise the business in how they can enable capabilities.

From my perspective, delivering IT projects, there are two significant gaps in PRINCE2. One the text readily acknowledges is the lack of guidance around specialist areas like IT. It is interesting given the genesis of PRINCE2 was to control capital it projects in the UK. The second is in transitioning the outputs into the business. Of the cabinet office products, MSP has the best guidance around transition, but what if your project is not part of a programme? Many it projects aren’t.

Now let’s consider the environment in which the projects are usually delivered. Rarely will a project be delivered in a Greenfield environment. Most organizations today will either have an infrastructure or existing capability of some manner. They have a framework for delivering to their business. More and more the best practice framework used is ITIL.

The process that wraps around service design, transition and operation in ITIL is the continuous service improvement process. This is responsible for measurement of existing services to identify areas of improvement to deliver maximum value. This is the crucial link to connect a service management framework like ITIL to a project management framework like PRINCE2. The organization has already put a value to having this service available to them. Tying this improvement process to business cases ensures what makes sense technically also makes sense strategically.

In a real life example … a software that is used by an organization was about to become unsupported. It was flagged as something needing upgrade. But the organization was thinking about changing business processes that would no longer require that software. The IT team had moved the cost of this upgrade into operational budget, so they wouldn’t have to go through a business case for it! What was the consequence? They upgraded the system, delivered within budget and time, but discontinued it in less than 4 months! Was this a successful project?

Paradigm is shifting in the way IT delivers to the business. Cloud is becoming a realistic option for many services, applications and even infrastructure delivery. The advantage of this approach is a known risk pattern and the level of elasticity it gives you. The fact that you can scale to demand and not have to design for peaks, are good ingredients for success. Custom development therefore should be the exception, rather than the norm. It is somewhat ironic coming from someone that started his career as a software developer.

There will be times when you will have to build custom systems. Either due to legislation, or simply the problem is unique. In my experience, software development is part science … we’re building machine instructions, part art … designing user interfaces for example … and part voodoo. The problem the customer explains, the BA understands, the developer codes … are often coloured by their interpretation of the problem. It is the role of the project manager to ensure the language isn’t muddled. This is where I have found agile practices very useful.

Agile methods allow for quick feedback cycles – starting early and often. The biggest benefit I have found is stopping unnecessary features being developed – all developers are guilty of that, trust me. It also ensures what is delivered does not come as a surprise to the customer. Agile requires delivery of working software at the end of each iteration. Lining iteration boundaries coincide with management stage boundaries will ensure if it is ever determined that the project is unlikely to deliver the desired benefits and is cancelled; the customer is left with the latest working product.

The model I strived to establish in projects is Continuous Service Improvement forming the basis for startup activities, using the service design principles during initiation as you define you product description, use agile practices to build the product and use transition processes to deploy to the organization and finally as part of closure to establish the operational practices so a new cycle of service improvement activities can begin.

I want to end by sharing a statistic from Keith Ellis of IAG consulting … only 1 in 3 software projects make it to completion in the United States. That is the good bit. Of the ones that do, 85% are late and over budget. Traditional project centric thinking has a lot to answer for in IT project failures. We must tailor PRINCE2 in context of the delivery environment and project challenges. Frameworks like ITIL; practices like agile can help us achieve that.

%d bloggers like this: