Hi there! If you’re a project manager, you’ll know that many projects (especially system implementation projects) tend to get into trouble. I recently saw in a CIO article that 50 percent of companies had an IT project fail in the last 12 months!
Fifty percent! This is an alarming statistic, if you think about it. It also begets the question “why project management is not well done in corporations”. This is something I’d like to try to answer in this article.
In my opinion, a strong contributor to project failure (and particularly IT project failure) is the lack of strong project management. But what do you mean by “lacking”? Let’s try to understand that more in the following.
Why is project management not well done in corporations?
1. New Project Managers
I hate to say this, but many companies and clients I’ve worked with over my career tend to have very, very high turnover in their “project staff”. That includes project managers, business analysts, testers, etc.
Many of these project team members leave a company after two to three years. I don’t know why, but it could be due to a boredom, a lack of job security after their massive project has been delivered, or just plain fickleness on the part of these people.
As a result of this high turnover, what you see is that many companies run projects using new PMs who have hardly worked one or two years there.
These new PMs could be very senior people – usually brought in for their expertise in program management and have at least a decade’s worth of experience.
However, they would lack the knowledge of the company and really to “build up” their stakeholder network and gain the trust of different departments. And you and I know that is one of the toughest things to do in the corporate world – obtaining buy-in to your ideas.
So what happens? Usually these “New PMs” in the company struggle. Many of them put up a bold front, promising that issues can be resolved quickly, keeping up stakeholder engagement, etc. But the truth is, many of these PMs leave (or are thinking of leaving), particularly if they work in an “end-user environment”.
In my humble opinion (and this is just my view) – being a PM in an “end-user environment” is not a nice job. You have TREMENDOUS pressure to deliver your project on time and on budget.
However, before you can do that, you need to get stakeholders to buy into your ideas. And in order to do that, you need to have credibility and trust, gained over many years of working with these stakeholders.
This is something a new PM will find very hard to do. You can’t gain trust and credibility if you have a tight deadline to meet. These objectives are just not compatible with each other.
2. Lack of Senior Management Involvement
I’ve written about the lack of senior management involvement in critical projects over here. Senior management support is a MUST in large scale projects. If you don’t have senior management support, contentious issues that cannot be resolved at the working level will remain “stuck”.
The most successful projects I’ve been on have senior, C-level executives who are actively involved. They are interested in the ground issues, why things are not moving, and do their level best to push things forward. Sometimes that means asking one of their department heads to accept “workarounds” in the short term so that the project can “go-live”.
Repeat – this kind of support is a MUST in projects.
3. No Culture of Project Management
The next thing that causes poor project management in corporations? I’d say it’s the lack of a “project management culture”. Some mature banks (e.g. Deutsche Bank, UBS, Credit Suisse, Citibank) – have very robust project management organizations.
There is a dedicated project management department which has control over project resources, tools and templates. Quality assurance and project governance are all administered by this team and they ensure consistent and effective delivery across different types of projects.
Case Study: When I was working on retail core banking transformation project for a Malaysian bank, I was quite impressed to see that there was a full-scale “TO” or “Transformation Office’ – comprising of project managers, business analysts and testing resources. These folks were all skilled in PM methodologies, had tools and systems for requirements and testing – and they ensured that all projects were delivered to an acceptable quality.
That meant that they had checklists to check every work product in a project conformed to standards, that business cases were robust, etc. I think all organizations should strive to have a team like this. It helps both vendors and in-house resources deliver projects much better.
4. IT is Part of the Problem
One common viewpoint I see in my clients – especially when IT projects go wrong – is that IT is part of the problem. This is detrimental to the morale of the IT department and also causes many projects to fail.
For example, if the system is slow in performance, it MUST be due to IT messing up.
If the system cannot support the launch of a new product, it MUST be our “lousy IT resources”.
If business users think that IT is the problem, then they will likely “throw issues over the fence” to IT to fix. They no longer work hand-in-hand with IT to resolve problems (which should be the case).
I think IT takes too much of a beating in companies and CEOs should take the effort to recognize that IT is doing the best they can. As with all systems, there WILL of course be issues. To say there is no system degradation or issues at all would be unrealistic. What is important is that IT has explored all possible means of remediation to fix the issues and that they are reporting regularly on what progress they’ve made.
In my view, that would be enough to demonstrate that IT is “part of the solution” – working to improve systems in the company, rather than being part of the problem.
5. Lack of Domain Knowledge
Anothe reason why projects fail in large corporations? A lack of domain knowledge. Too many project managers I know have no knowledge of the domain they’re working on – be it wealth management, private banking, retail banking, commercial banking and investment banking.
I’ve written a lot about why domain knowledge is important in project work. You need it to at least gain some credibility with your business users and stakeholders.
Can you imagine interacting with e.g. the Head of Relationship Management or Head of Credit in a private bank and have no idea what they’re talking about? Or spouting something about private banking that clearly demonstrates your lack of knowledge? That would be embarassing, not to mention it’d lower your credibility in getting things done in the project.
To explain this a bit further – note that you don’t have to be a deep expert in the banking domain to be a successful project manager.
In fact, the ideal PM in e.g. a banking environment is someone who knows ENOUGH about the business but does not go too deep. I’d be wary of a PM who knows, e.g. the client KYC process extremely well but is not well rounded and doesn’t understand trade settlement, credit monitoring, portfolio management, etc.
A PM in this case should ideally have a broad knowledge of the banking industry and how banks are operated (from front to back office). This enables him or her to converse intelligently with senior stakeholders and make an impact.
So lesson learnt – go gain some domain knowledge as a PM!
Wrapping Up …
In the above, I’ve gone into some depth about why project management is not well done in corporations. Whether it is due to new PMs, lack of senior management support, lack of a PM culture, or other factors; it’s clear that the situation needs to be cleaned up.
I believe that as a PM, if you monitor the above symptoms of poor project management and try to correct them, you’ll have a much higher chance of delivering future projects on time and on budget.
That’s all I have for now. Until next time, have fun doing project management!