Project Management in Practice

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

Tag Archives: Business

5 Must dos for recovering failed projects


NovopayAs I was writing my last post on Novopay, I was also contemplating how one can rescue such a project. The minister in charge, Stephen Joyce has announced a $5M fund for addressing the issues. How would this work in real life? Reports are rife that the government wanted to get its money back from Talent2. That, along with the fact that relationships are already at breaking point, are not good success factors for the project. So what are some of the things that need to happen before you can achieve any improvement?

Acknowledge the failings

When doctors treat patients with substance abuse, the first thing they try to instil on patients is the acknowledgement that a problem exists. The environment around failed IT projects is exactly the same. It lurches from one problem to another while trying to apply band aids to keep things going. Until parties are willing to admit problems exist, there is no hope for a resolution. If you keep doing the same things there is no chance of the result being any different than what it is today. It is very likely that some within the project saw the train wreck coming and may have voiced it. Seek those out to understand what went wrong.

Divorce emotional investments

One of the basic practices of IT is that software developers do not test their own code. It is not because they are not capable. In fact, they should be more capable than anyone else. However, as human beings we are predisposed to not finding holes in our creation. Same is true for the management of the project. The current status is a reflection of many decisions taken through the course of it. Many in the management will feel the decisions were correct at the time with the information they had at hand. You need to remove the management decision makers from both the supplier and customer to ensure progress. Leaving them intact will risk required changes not happening. If the changes do happen, it risks those people losing their authority as they have been “proven” wrong in hindsight. To top manager from the public service, Education Secretary Lesley Longstone has already resigned. If the same has not happened from the supplier Talent2, that needs to happen.

Aim for small wins

In a major failure it may sound couter intuitive to look for small wins, as the problem is a sizeable one. Most adults are reasonably sensible and not easily taken in by bulls**t. They are well aware that a major failure like Novopay is not going to be resolved quickly. What you need to achieve at all costs is some confidence among your user base that improvements are underway and they can see a light at the end of the tunnel. Bigger your ambition is, more balls are in the air and higher the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements often and communicate honestly.

Throwing more resources is not always the answer

As Fred Brooks Jr has pointed out, the most reliable software is written by one or two man bands. The need for quicker output requires many more developers and as a result introduces complexities several folds. One of the major reasons projects fail is because communication is poor. Having large teams working on it is therefore more risky than the original projects. It is a common tendency in projects to throw more resources at a problem. That is just about the worst things you can do in a failed project. With smaller wins go for smaller teams.

Be prepared to abandon the project

For all the best will in the world sometimes you will not be able to retrieve failed projects. Cost of retrieval may be higher than doing another project from scratch. It also may not give you the benefits you were after based on the additional cost. You may find there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful to be seduced by that. It is difficult to contemplate ditching a system like Novopay as that cannot be done without a replacement to pay the teachers. Supermarket chains, farms and IT industry contains a lot of similar requirements with a considerable part time contract staff alongside permanent staff with various levels of skills and entitlements. A fully functional system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.

Have you worked on recovery of a failed project? I will be interested to hear your feedback on Novopay or even failed projects in general.

Related articles

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.

Australasian trends in MSP and impact on PRINCE2


The Wellington PRINCE2 User Group met last week at the Deloitte House. The guest speaker at the event was Geoff Rankins, a programme and project management professional with over 35 years of experience across ASX50 organisations, Federal and State Governments in Australia and international not for profit organisations. He is also a contributor to PRINCE2 2009, MSP 2011, ISO 38500 and ISO 21500. Usually the user group has a format of three seven minute presentations followed by Q&A and networking on a single event. Due to the calibre of the speaker the committee adjusted the format to have only a single speaker with interactive Q&A with the speaker. Three main threads of discussion centred around trends in Australasia, MSP implementation lessons and co-existence of MSP and PRINCE2.

There were some interesting insights from Geoff regarding the pattern of adoption he has seen in Australasia. Consulting firms are using MSP to manage company mergers and state wide eHealth programmes. One of the largest construction companies is using MSP to manage building of 800 building in an 18 month period across the state of Queensland. The Australian Government Information Management Office (AGIMO) is promoting the use of MSP to the Federal Government Departments. The Capability Development Group of the Department of Defence in Australia already use both MSP and PRINCE2. There is also a trend in the various State Government Departments using MSP to deliver strategic programmes. In Australia not for profit organisations are using MSP to deliver process re-engineering and coordinating national mental health programmes. In New Zealand telecommunications and hydro-electric companies are taking up MSP as well as the national rail company and the Department of Corrections. Internationally, UNDP has adopted MSP to deliver aid programmes across 160 countries and in the UK the London Olympics is delivered through MSP. If you were ever wondering why so many examples on the MSP text appear from the London Olympics, this is the reason.

Like any other change initiatives, there is different between deciding to use MSP and adopting it. Some of the implementation challenges Geoff shared has a ring of familiarity. The biggest issue he highlighted was not treating adoption of MSP as an organisational change project on its own. Unless the organisation changes the culture of its programme delivery, success is going to be limited if at all attainable. In the same manner PRINCE2 has to be tailored to suit the organisation, so should MSP. That leads to implementations not challenging the existing environments and the necessary organisational change is not achieved. Using consultants was also identified as a limiting factor. Consultants being used must have implementation expertise, rather than simple certifications. At the same time the organisation must invest in internal capability building. In many case consultants move and and all the knowledge is lost. Consultants can help implement, but not maintain and evolve the framework as the organisation changes.

There is also a tendency to jump to a solution mode too quickly, what Geoff called inadequate “optioneering” and resulting in sub-optimal business cases. Organisations where programme management is less mature there are tendencies to treat a set of projects as a programme and not using it a vehicle for achieving organisational change. This also leads to focus to too much detail at programme level – defaulting to project management mode. The senior management in the organisation have to focus on the bigger picture of the programmes, rather than details of individual projects. Intervening too low results is focus on outputs rather than benefits and threats to them. There also needs to be a realisation that programmes are inherently more uncertain than projects and some element of learning is expected. The benefit an organisation can derive from having a well defined MSP framework are providing quick start to project business cases, oversight in project governance, escalation path to the senior management, lessons capture and dispersal across many projects. The biggest benefit of all is the focus on benefits realisation – something a PRINCE2 project is tasked with considering, but not well placed to achieve as the project is long finished before the benefits are scheduled to be achieved.

Sometimes organisations spend too much effort to identify if something they need to achieve is a project or programme. The key message from Geoff was to start with either and change the approach if necessary as the business case gets refined. Integration of PRINCE2 and MSP should happen on the basis of roles, assurance requirements and governance strategies.  The idea that resonated with me was there is nothing stopping cherry picking parts of MSP into projects if the organisation is not mature enough to handle MSP implementation. There is no reason why stakeholder engagement strategies, benefits profiles, blueprint and transition planning concepts of MSP cannot be used in a PRINCE2 project. In fact those should be transferable to any project. Right tools for the right environment.

Adoption usually comes because of governance and accountability reasons. For that reason frameworks like MSP and PRINCE2 usually are adopted by Government entities first. This then forces all service providers to comply. It appears there is substantial acceptance of MSP and PRINCE2 as Programme and Project Management frameworks in Australasia.

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.

%d bloggers like this: