end of a project management methodology?

I saw an article that claimed that the PRINCE2 project management methodology and qualification is becoming out of date due to the growth of collaboration. This is contentious and reads like the claims that have been made over the years that ERP is dead. The proponents of the ‘PRINCE2 is dead’ seems to be the same ones that believe that ‘agile project management’ is the only way to run projects.

I wonder what the project management uber-bloggers Glenn Alleman and Josh Nankivel would think of the article?

From 99% to 100% complete is not 1%

A Harvard Business Review blog by Dan Pallotta, The Last One Percent that Kills You, reminded me of all those projects where we thought we had almost finished, only to find that the effort right at the end was far more than we expected so close to finishing.

A lot of that effort arises due to issues that we had thought were finalised, but weren’t. For project managers, Pallotta’s advice is:

•  
  • Beware the tacit agreement … We’ve all experienced a thousand conversations in which neither of us understood what was just said, but we both just let it go and implicitly hope for the best …
  • Develop a Pavlovian reaction to the words “I think.” When someone says “I think” it usually means they don’t have a clue, or are guessing, or even hoping. It’s in that space that an important detail gets dropped.
  • Have multiple conversations about the same thing … People forget things, and clarity can degrade into mush after just a few days …
  • Fill in the blanks. Repeat back what other people say in conversation and ask them to confirm what they said. Make sure you get a definitive answer …
  • Speak like an air-traffic controller [adopt the rigour of the language used by control towers and pilots – i.e., clarity and preciseness of communication]
  • Visualize disaster. Talk explicitly with your team about what could go wrong in each area …

If you want more good project manager tips, check out the über-project manager Glenn Alleman, or Josh Nankivel.

Joburg City’s project failure record

Last year I wrote about the problem with the billing system that Johannesburg City Council had implemented. The project, a SAP-based implementation internally called Project Phakama, is in the news again for all the wrong reasons. According to one report, the project has cost the City over R800 million (over $100 million). The situation has reached such a bad state again that there was a report that central government was considering stepping in.

This is obviously a highly strategic and visible project, and it’s not uncommon for these kind of ‘heroic’ projects to have very public bugs. As I mentioned in my previous blog about this project, SAP had won a quality award for it, but has readers of Michael Krigsman’s Project Failure blog will know, the software is only one part of the issue.

In the ‘Billing Crisis’ news report, an opposition spokesman says the problem is that it is a complex system

“…and people have not been properly trained for the system”.

In another news report:

‘The city’s head of finance, Parks Tau, said implementation of the IT project had been completed and that problems with it were “interface-related”.’

So here we have two issues which need to be addressed – people-related, and external systems.

On the one hand, the project owners (City officials) seem to be saying that the project is nearly done. On the other, they don’t appear to have the complex IT project experience to know “What ‘Done’ Looks Like”, to use Glen Alleman’s phrase.

SAP is fortunate that it is not their name that is being publicly criticised, as has happened in other municipal projects.

One thing I am glad about – that I am not the vendor or implementation partner project manager on that project.

Update #1: SAP have distanced themselves from the project – ‘Don’t blame us‘

Update #2: The story behind the project chaos is revealed – The connections that disconnected Joburg

The need for IT project management

The Herdings Cats blog had an article:

CEO/COO/CIO’s not confident in IT Project Managers, really?

In a number of companies, particularly in small- and medium-sized busineses, CxOs do not like project management (PM). On the PMForum there is a report that while CxO’s see PM as critical, they have little confidence in project managers.

PM guru Glen Alleman makes the observation that in many commercial IT organizations:

Project Management is an afterthought … [with] none of the oversight and progress reporting, no wonder the CXO’s have no confidence. They get what they deserve. PM costs money, don’t spend the money? Then as Dr. Phil say "how’s that work’in for ya?"

Project success or failure: Johannesburg City Council

If this was somewhere in Europe or the US, the international commentators would be all over it, but as it’s Africa only those of us living here are the ones making a fuss. I am talking about the Johannesburg City Council’s SAP-based billing system, Programme Phakama, and the point in question is how do you define project success or failure, something that Michael Krigsman covers frequently. 

The goals of the Phakama programme were to centralise the city’s billing databases and replace multiple, disparate IT systems, in order to improve accuracy and completeness of the billing and invoicing process, and improve levels of collection and client service. Land information systems would also be integrated into the billing system, allowing the city to bill residents according to the correct valuation and usage - Joburg promises billing progress.

At the end of June, the city council announced that it had been awarded a SAP Quality Award for the successful implementation of the programme. The problem is that only the city council seems to believe this has been a successful project. Earlier this year, problems were being reported about the ERP implementation. When SAP was questioned about the award, the response was that the city “was nominated because of its clear governance policy and for implementing the project on time. It competed against 19 other companies in Africa for this award.”

That sounds to me like the criteria for project success were based primarily on budget and on-time measures, and that other issues around data quality and customer service were not really considered.

According the online article, SAP fails to explain award, opposition councilors “find it difficult to understand how the system picked up the award.” Since the end of July, there are have further articles on the problems resulting from the project, culminating in a recent article “Reputation suicide: SAP’s presentation of a Quality Award to the COJ’s billing system must mean it does not want to look like a high-standard, sane company anymore.”

South Africa has just completed a ‘really mega-project’ called FIFA 2010 South Africa, which 99.9% of people believe was highly successful and showed that we could deliver on all the important metrics – time, budget, quality, safety, service. It’s a pity that a project that affects thousands of people in Johannesburg did not have the same project management and oversight. There are similarities to Home Affairs IT project failure, and it leaves me concerned that management of major IT projects in South Africa does not show the same level of skill and attention that big projects like FIFA 2010 had.

On the other hand, big IT projects fail all over the world, as Michael Krigsman continually points out, so maybe we shouldn’t feel too bad.

Home Affairs IT project failure

Michael Krigsman makes a living from the subject of of IT project failure. There are a number of issues he discusses on project failures:

• early warning signs of project failure
• the Devil’s Triangle
• bad leadership

There was report in the South African Sunday Independent on 18 April 2010 which highlighted a number of the issues Michael has covered. The report concerned the bungling of the multi-billion rand contract awarded by the South African Department of Home Affairs to black-empowered IT company Gijima AST. (Note: The Sunday Independent only gives access to articles online for subscribers of its print version).

In a memo by the consultant whom Home Affairs contracted to manage the project, some typical IT failure issues were mentioned.

1. Lack of project ownership by the client (Home Affairs), leaving Gijima to determine and drive the project deliverables, and making project governance difficult.
2. Lack of involvement and support from the client executive sponsor.
3. Poorly defined business case, little budget commitment and continually changing project priorities. Points 1 and 2 create this situation.
4. Low level of capability in the client making it difficult at the IT level to get agreement on technical architecture and design specifications, as well as at other levels.
5. Lack of end-user skills in the client to enable the project to achieve objectives.

Reading the article made me sympathise with the project manager, who I once worked with at one of South Africa’s big banks.

The question some South Africans are asking is how and if Home Affairs and Gijima can patch things up and get the project going again. From this South African’s perspective, however, one question is how would you go about reviving this project. A place to get ideas would be from Glen Alleman’s  discussion on Project Disentanglement. The other question would be, for such a high profile and high risk project, who would be prepared to take on the project management role.

How would you go about getting such a big government project back on track? And would you even want to?

Project management is a serious business

I have used this title because I’m not sure whether new entrants to software development realise what a difficult and stressful job project management is. It seems that some people think that being a project manager (PM) is a ‘cool’ job because they have watched the reality TV program The Apprentice where in each program ‘project managers’ are appointed to manage each week’s activity.

I have been involved in various software and ERP projects on and off for close on 10 years, and unless things are going very well, I found that being a PM is a tough job.

If you want to get an idea about project management, follow the über-PM blog – Glen Alleman’s Herding Cats. He can get quite technical at times, especially concerning US defense and aerospace requirements, but has some great points. He points out the the key to managing a project is the following:

• how do you evaluate what DONE is;
• how do you determine where you are along the way to getting to DONE.

Here are his immutable activities of project management – “immutable because in the absence of these activities in some form, there is no management of the project”.

When I first started as a PM, risk wasn’t an issue we really focused on – if a project went over time or budget that was a problem for the business, IT’s job was just to deliver. But these days, that attitude has changed radically (and for the better). To understand the risk management process, here is a diagram I got from Glen’s blog.

Mary Gerush at her Forrester Blog noted the skills that software project managers need to have in order to succeed:

1. a solid understanding of the business;
2. a solid understanding of technology;
3. a strong foundation in project management practices;
4. most importantly – an amazing array of updated soft skills.

One of the critical soft skills is an understanding of psychology. Projects are all about people – whether it’s the people on the team, or dealing with the stakeholders of the project (the business sponsors). I know some PMs who are very good on items 1 to 3, but fail badly on item 4.

Finally, for a light-hearted look at what project management, here is a great analogy – Five Parallels Between Golf and IT Projects. The ones that stand out for me are:

• it looks simple but is not;
• a very small error can lead to major problems;
• it’s remarkably easy to second guess others – it’s easy to be an expert, with hindsight;
• it’s very difficult to sustain a consistent level of performance.

Are there other aspects of project management, which I haven’t covered, which could be used as a PM primer? In some industries, project management is now taken seriously; banking I know is one (aerospace and pharma are others, I believe). But in too many small and medium businesses, which is where my experience has been lately, the concept of project management still isn’t very well understood or appreciated. The question is – where and how to start the process of education?

Can you say ‘stop’ when customers ask too much?

I differ from Kimberling’s blog Four Reasons Why ERP Projects Take Longer Than Expected, that ERP project timelines are due to software vendor sales people under-estimating issues and implementers finding unexpected customisation needs.

It can happen with some projects, but in my experience it is unrealistic expectations by customers of when the implementation should be completed and what to be included.

On The Art of Project Management blog, there are some good points on the whys and hows of Saying No.

It’s not easy to say ‘stop’ or ‘no’ but too many projects have got into trouble because either of those words weren’t said often or soon enough.

Project Communication

A couple of posts on Paul Rasmussen’s blog prompts me to make my own comments about communication between members of a project team. In The Problem of Communication in Project Management Part 2, Paul discusses the types of communication currently used, which are meetings, phone calls and emails. In Part 3 he mentions new communication technologies – smart phones, wikis and social networking.

Having just been through two projects, I have found that the old ways of communication, particularly face-to-face, are the best for project communication. As we all know, more than 50% of our communication is non-verbal (ie, body language, voice tone), and also as we know, projects success is highly dependent on communication. So as in the case of one project manager, most communication was by email, then mis-understandings can happen. Our company has now instituted a directive that email is not considered adequate communication.

We have tried collaborative tools, such as Basecamp, to help with dispersed team members, but there seems to have been some reluctance to try these new tools. I find that interesting, considering we expect our clients to adopt new tools in the form of ERP solutions. So whether we would benefit from new communication technology is up for debate.

Email can be used to confirm and document facts and issues, however in my opinion, nothing replaces personal contact when it comes to communication.

Why are ERP consultants needed?

In a blog on the ITtoolbox site, Steve Phillips comments that companies are moving away from using external ERP consultants in favour of using in-house expertise – Why ERP Software Consultants Cannot Save The Day.

His view is:

The ownership philosophy is about controlling your project destiny and built on some fundamental principles. … 1) It is possible to take internal responsibility for project management. 2) It is possible to develop and/or acquire internal software expertise to the point outside application consultants are rarely needed. 3) It is possible to become much more educated and less reliant on the false sense of security an army of consultants can bring. 4) It is possible to realize ERP benefits by developing better software and business process solutions with fewer outside consultants. 5) It is possible for internal personnel to do up to 70% of what many pay consultants to do.

Except for item 4, in my experience, I haven’t found any companies that can do what he suggests. I suspect it is a function of certain factors – a primary one being the size of the organisation. But I also believe that business maturity, and the availability of knowledge and experience play a significant part.

In the South African market, most businesses fall into the small-to-medium (SMB) category. Employees in SMB companies tend to take on more than one role (debtors and creditors, pre-sales technical and sales, production planning and management) which leaves them little time to focus on issues which are not directly relevant to the job they must do. So finding time to acquire software expertise is difficult or requires after-hours learning. In time, and if a person stays in the same job, they might become “more educated and less reliant.” However, given their time constraints, it is highly unlikely that people will have the time or knowledge “to do up to 70%” of what a consultant will do.

Also skills and expertise are in short supply in this country, so someone who develop technical skills may easily find themselves moving out of their business job and into a technical or consulting role. Similarly, project management requires experience and time to spend on it, which senior staff in SMBs (e.g., finance managers and directors) rarely have. Companies will tend to have a less senior person overseeing the project, but all the details and work that goes into project management has to be done by someone with the background and time allocation to do it – in other words, a consultant.

In the South African context, therefore, most average companies (not large ones over 1000 people) do not have the people, skills or time to take on an ERP implementation themselves. The cost of bringing in consultants outweighs the risks of failure in trying to do the project in-house.