Project Management in Practice

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

Category Archives: Stakeholder management

The value of stakeholder management


Mosaicproject's Blog

One of the questions I’m regularly asked is to outline the business case for using stakeholder management in a business or project. This is a difficult question to answer accurately because no-one measures the cost of problems that don’t occur and very few organisations measure the cost of failure.

The problem is not unique; it is very difficult to value the benefits of an effective PMO, of improving project delivery methods (eg, improving the skills of your schedulers), of investing in effective communication (the focus of my September column in PMI’s PM Network magazine) or of better managing risk. The costs of investing in the improvement are easily defined, but the pay-back is far more difficult to measure.

There are two reasons why investing in effective stakeholder analytics is likely to deliver a valuable return on investment (ROI).

  • The first is by knowing who the important stakeholders are at any…

View original post 1,332 more words

How do I balance competing investment priorities?


Organisations are forever grappling with the demand of competing investments that give a varying range of benefits. How do they go about prioritising these? Most organisations use business cases as a means to filter out the projects that deserve funding from the ones that have little or no merit. This then introduces a secondary problem of spending a lot of resources on going through a business case, which will never see the light of day. How do you make sure weak business cases do not get all the way before getting knocked back.

Example-ILM-Rail-Freight

Investment Logic Mapping (ILM) provides a good way to filter out some of these early investment dilemmas. This is part of the Investment Management Standard developed by the Victoria Department of Treasury and Finance in Australia. The main driver for the development of this standard was the number of complex investments that required compliance, but never articulated the benefits they were supposed to deliver.  Effectively what started as a mechanism to shape individual investments in 2004 has now matured into programme and organisation levels – including refocusing organisations and monitoring benefits.

The theory behind the standard is quite simple. Rather than a complex set of tools, it is centred around three key concepts

  1. The best way to aggregate knowledge is through an informed discussion that brings together those people with most knowledge of a subject.
  2. The logic underpinning any investment (the ‘investment story’) should be able to be depicted on a single page using language and concepts that can be understood by the lay person.
  3. Every investment should be able to describe how it is contributing to the benefits the organisation is seeking.

In Victoria it is now mandatory for most significant investments. In New Zealand the State Services Commission (SSC) mandates the use of ILM for High Value or High Risk (HVHR) projects as part of its Better Business Cases initiative. It must be remembered that ILM on its own is not the tool that will drive the investment. It is a tool to eliminate initiatives which lack merit.

I have just recently undertaken an Organisational ILM as part of a strategic review for an organisation. I have found it an excellent tool to bring out the challenges in an open forum and to agree on strategic responses. The two hour session was perfect to get enough senior leadership in one room to work through the organisational challenges. I also found it a good use of senior stakeholder time, as they are busy people and often trying to agree a course of action individually with all of them is a significant barrier to change programmes.

If you have used ILM before, I’m keen to know your experience. The only thing I had forgotten is being on your feet facilitating for two hours, while everyone else is seated discussing and having refreshments is quite tiring.

Should government be in the business of IT?


I was reflecting on the news during the week that a second head has rolled in the Novopay debacle. After Education Secretary Lesley Longstone, Deputy Secretary Anne Jackson has also fallen on her sword. There has been some interesting commentary regarding the extent government should be involved in IT.

should government be in the business of ITGovernment policy changes as often as election cycles, sometimes even more frequently with change of ministers. It seems quite a common consensus around the developed world that government is gradually stepping away from providing the IT services and replacing with suppliers. I have worked most of my career in the supplier space. Still I wonder if sometimes it provides the best outcome for the governments. There are good reasons to outsource to experts. Are there equally good reasons not to?

In my experience, those of us working in IT have an inflated sense of self worth. We tend to forget that IT is almost without exception an enabler of capability. No one does IT because they need to deliver IT. It is therefore a support activity to help core deliverables of an organisation. It is argued that this activity should be outsourced to experts to deliver. Expertise in IT does not equal expertise in delivering the business outcomes for the organisation. This distinction is not always made.

Quality in any IT service delivery is relative to the the context. You can provide a quality service only when you build up knowledge of the outcomes the organisation is trying to deliver. A good understanding of the constraints are also needed for success. These are constantly evolving. In a usual scenario a number of suppliers will provide a range of services to an organisation. Typically none will have visibility of the end outcomes desired. There are so many instances of projects delivered to specifications that do not deliver business benefits, it is frightening.

The pressure from bean counters to reduce head count has resulted in false accounting. People are very resourceful and learn to manipulate systems to get what they need. By reducing IT head count, the cost is passed on to specific projects. When suppliers are engaged in those projects, government is paying for the actual cost to deliver the project + contingency applied by the supplier + supplier’s profit margin. Even if you retain the same vendor, you are not always guaranteed retention of intellectual property. In reality the cost to deliver the same outcome is no less, and is likely to be significantly more.

I do not see government contracting model encouraging sharing of risks and rewards. Contracting method encourages offloading risks totally to the other party. This results in most contracts being administered in an adversarial way. Where deliverables are provided for a fixed cost, suppliers will always try and deliver minimum that will pass acceptance, rather than trying to maximise outcomes. Where many individual contractors are used, I have seen instances where they have tried to stretch out the delivery in subtle ways.

The role of the government is to deliver a service to the taxpayers. All that is required to deliver the service in an effective and efficient manner should be part of the role of government. A government department has its own legal teams and human resource staff. Why should IT be any different. This is even more critical considering the long list of failed IT projects. Disagree? Let’s discuss.

5 things to do when projects go wrong


5-things-to-do-when-projects-go-wrongAnyone spending a decent amount of time in project management field will sometimes have projects from time to time that experience significant difficulties. For all the planning, it is never possible to predict all the eventualities and therefore foreseeing all risks. Projects are by nature more risky than other business activities. It is always useful to apply a few techniques to aid in such situations.

1. Show leadership

An oft repeated cliché this is something that is hard to explain in terms of action. When things go wrong there is plenty of nerves in the project team and management. Project team members often struggle to think beyond their immediate problem. You will find internal executives or sponsors worrying about contractual obligations and any fallout with the customer. Showing leadership in this context is to ensure this uncertainty does not spread into panic. The role of the project manager is to steer a clear course and stopping any blame game that may raise its ugly head. Now is not the time for that. Focus on why after the project.

2. Avoid temptation to simply throw more resource

A common reaction to a struggling project is to throw more resources at it. If the project is of high visibility and management is not able to provide subject matter expertise, they will feel they need to contribute somehow to correct it. The commodity at their disposal is resources. Be wary of this. More cooks do not equate to a better dish. You may need to enlist some mentoring for project team members or even yourself if you are managing a project outside of your technical expertise. Always consider how much time it will take before new resources can contribute to the project. If the issue is time, you will virtually ensure a delayed delivery by adding resources. Also take into account the additional communication required to successfully integrate them.

3. Avoid sugar coating

There is a temptation to play things down as things start going wrong to avoid creating panic. I have found it easier to be transparent about progress. Late surprises will compromise integrity of the project like no other. While your stakeholders likely be upset with you, in the long run it will get you more respect. You need to be clear with communication internally. If you need some of your resources to be allowed uninterrupted project time, you need to give that clear sense of urgency. Otherwise, you will not get the outcome you desire. Clear does not mean antagonising your people. You may need the same people later in the project or for a subsequent project. Do not burn bridges.

4. Undertake review

Very often when a troublesome project is completed, people are so pleased to see the back of it, no learning takes place. This is just about the worst thing you can do. You are not making sure same problems are not repeated. Wait for a reasonable period after project closure to undertake review. While things are still raw, people are more likely to be defensive and the value you get from the exercise will be limited. When you review, structure it so everyone has the ability to come forward with what they could have done better. Start yourself to show the way. If people are forthcoming, leave it at that. Your aim should be to avoid repeat, not to be punitive.

5. Follow up

Do not leave the review in a document and expect the next project to pick up on it. Use the information from your review to recommend training plans and process changes for the organisation. Present these to someone with influence within the organisation. After some time follow up on progress of the recommendations. Improvement takes hard work and tenacity.

Do you have any rules for managing troubled projects? I’d be very keen to hear.

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
%d bloggers like this: