I've seen many projects that were rollout successfully(within budget and dateline) but turns out to be a 'white elephant' (where everybody praise about it but nobody use it).
How to avoid your project from becoming another 'White Elephant'? Saving Changes...
Sort By:
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Josh Nankivel has recently posted a blog entry 'Sell Your Teams on Why!' that basically talks about this. Basically, it is based on selling people 'why' a project is initiated and executed in the first place instead of selling to them 'what' you want to do. You may want to check it out in the URL below.
Shoaib AhmedProgram Manager| Eagle Technology GroupWellington, New Zealand
This is one topic where I find PRINCE2 provides an excellent process. The key is to ensure your business case is continually justified through any of your project stages. You must include user representatives as part of your project stakeholders. If a business case is not justified, the project should be stopped. This way, you do not create a white elephant, as you say. Saving Changes...
most of these 'white elephant' projects' business case were justified.. that's why the project were initiated and implemented. However, the end users are not using it.
In another word, the management wants it but not the actual user. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Perhaps there is no one driving it down from the top and no one communicating the purpose of the project. It could also be that the objective of the project is clear but what is being delivered does not match with the original objective of the project and therefore, turning it into white elephant. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Or it could be like what you said Michael, the project was justified by a group of people and it actually affected another group. For instance, IT team is pushing a high-end application for the business users when they don't think they need it and don't understand 'why' they need to use it. I believe change management is important in this aspect. Saving Changes...
Shoaib AhmedProgram Manager| Eagle Technology GroupWellington, New Zealand
This is where you must have senior user reps as part of your project boards. Business case is not simply something you do to justify a project. You review your business case at each project board meeting (whatever shape or frequency the meeting may be). If the user reps saw no benefit in having the project, it is their responsibility to say so when the earliest realisation comes. This is the role of project governance. If the user reps do not raise this, then it is they that are responsible and should be held to account by management. If they do raise it, then the management has the opportunity to kill the white elephant without going through the motions and completing the project.
There is however, no cure to silliness. If the management is warned and still continue with it, then a white elephant is exactly what they deserve. Saving Changes...
In many organization especially in Asia (i'm not sure elsewhere), the management love those 'YES-MAN' Manager (agree to everything their boss said because he was hoping for a promotion,etc) and hate those who object their request. So, when the project was assigned to these 'Yes-man', he/she will force it down the throat of all the users to use it (whether the users like it or not).
I was once assigned a project to integrate two organizations system into one complete system. Both the organization management doesn't like the idea (because their business direction and need are different), the users don't want it, and even my boss know about how much they hated the idea but the final answer I got was..."the Minister wants it"... and nobody dares to say no to the minister 'great vision'.
Sometimes it is not about how well you manage your project or well written your business-case, office politics will always be a part of Project Management. Do you have the gut to say NO to your boss's boss' boss? :P after your boss's boss had agreed to deliver that project. Saving Changes...
Shoaib AhmedProgram Manager| Eagle Technology GroupWellington, New Zealand
Agree with Michael. There is always an element of politics in projects. It is not the role of project manager to say yes or no. That is the role of a project board (the people that the project manager is running the project on behalf of). The role of the project manager is to provide professional management (control scope, cost, risk, quality, time) within the limits given to him/her.
In your scenario, if the minister has already hijacked the governance project, then there is no way you can avoid a white elephant. In that scenario, my aim will be to deliver what is agreed and leave the project board to account for the benefits (or lack thereof). Sounds a bit cold, but the only way. A doctor cannot treat a patient who won't take medication. Saving Changes...
I agree with Shoaib, it is not a project manager's role to determine or realise the benefits of the project they are managing. The success of the project manager is delivering on time and buget, the success of the project is based on the realisation of the benefits and that is the role of the project sponsor.
During the life of a project any changes should be compared to the business case to ensure that the benefits are not being eroded or the costs increased beyond what the benefits will deliver. The go /no go decision is again the project sponsor. Don't forget to update the busines case with the new numbers if the change is approved.
What the project sponsor wants, as their agent the project manager delivers. Saving Changes...
I like Shoaib phrase "A doctor cannot treat a patient who won't take medication"
and I also agree with Julie's idea that we should evaluate the project benefit at every project life cycle (i.e. Toll-gate at every project stages: Initiation, Planning, Execution, Monitor and Closing), adding a little Six-Sigma essence into the PMI.
