If you have been working in IT industry for a few years you might have been part of at least one project that was closed midway.
I’ve been part of a couple of them myself.
And it’s not a good feeling when that happens, is it?
Projects are closed for various reasons – sponsor abandoning the project, lack of funds, an idea whose time hasn’t come, bad execution, and many more.
As a project manager, there IS something you can do proactively to avoid a situation, or at least lessen the impact on your team when the project does get closed for reasons beyond your control.
The first thing is to look out for signs.
The ominous ones.
Star Wars Fan?
At the end of this post you’ll get a downloadable inforgaphic. I’d suggest print and stick this to your work desk, as this acts as a guidepost for some of your day-to-day decisions as well.
You’re going to love it if you are a Star Wars fan!
Some of them are given below. Few of these are given possible action item(s) [remember, a situation can be handled in more than one way].
Also read: 4 ways to deliver bad news the right way to the team.
1. There is no detailed project plan
The only thing sure about a project is that at some point in time, something will go wrong.
And when that happens you need to fall back on the project plan (and for many other reasons, of course).
If there is no detailed project plan, that means only one thing.
There are plenty of assumptions.
And most of them are residing in the brains of various key people on the project.
And that’s a big flashing red light for the project manager.
Action item: Get a detailed project plan. Of course. This may not be possible always, for various reasons, especially if the project manager joins a running project and discovers this ugly truth. And the dreaded one is there are no clear requirements, and hence planning is not feasible. This is a situation the project manager must avoid at any cost. If there are no detailed requirements, raise the red flag. ASAP.
Talk to the sponsor, product manager, customer – whoever is responsible for getting detailed requirements. Set up a small team, hire a person – whatever it takes to document requirements. And then the project plan from there.
2. There is no identifiable senior management person championing the project
In other words, the project does not have a sponsor.
Bad omen.
And surprisingly, this can be a common situation. Sometimes this may be a false positive case. Maybe there IS someone responsible for supporting the project and probably she is not told, or it is not communicated to the project manager. In any case, the project manager must find out the sponsor and understand their perspective of the project.
Action item: Your manager is the first stop in locating the project sponsor.
3. Customer has not been involved in product definition
Consider these facts –
- Product requirements change over time.
- The project takes time to complete – from a few weeks to months (if not years).
- The project must be delivered to the customer.
- The customer is supposed to evaluate deliverables and sign off on the project.
- If not, the repercussions may impact the revenue of the performing organization.
- The project manager’s bonus (even promotion) depends on the success of the project. Among a zillion other things, of course.
These are enough reasons to make sure the customer is involved in product definition and during regular product review meetings.
Action item: yes, understood.
4. There are no formal processes in the organization
If the performing organization (PMPism used to refer to the company implementing project) is small in size or in existence for a few years, chances are that the environment is chaotic and there are no formal engineering, quality control, or quality assurance processes.
Action item: Talk to PMO about processes and policies. If PMO does not exist, find out from other similar projects. If nothing exists, this could be your chance to rise and shine.
Use your PMP knowledge to set up processes and make sure other projects also are benefited.
Image courtesy: bushkov
5. There are no proper project tracking tools and/or the project is managed using MS Excel
Well, to be honest there many projects are managed just on Excel even today. Especially if they are sort of run-of-the-mill types, short ones. This by itself need not be a red flag, but combined with other factors this can be detrimental to the project’s health.
The project manager is the best judge to identify the right management tool that highlights problem areas and gives good project metrics.
6. There is no change management process
As they say, the only thing that is constant in life is Change. Holds equally good for projects.
Changes are to be expected, welcomed, and managed. With a process, ideally. (PMBOK identifies one).
It really, I mean really, helps to have a formal change control board. And it would be a cardinal sin not to include someone from the customer side on this team.
7. Team works almost all weekends and holidays
Bad. Bad. Bad.
I am sure there will be at least one person on the team who would WANT to work on weekends and holidays (no, this is not an intended joke on married people 🙂 ). But a project manager would make sure that,
(a) such a situation does not arise (I know it does happen once in a while – which should be okay, as long as there is compensation planned out)
(b) such practice is discouraged
..for obvious reasons that,
(a) it reduces productivity
(b) burns out the team
(c) causes morale issues
and so on.
Action items: Project planning must take into account all holidays (of the performing team, customer team, and vendors), personal vacations, and weekends while planning delivery schedules. These should NOT be treated as ‘buffers’ as some projects do. Even the risk register should contain entries if there are risks in view of delivery expectations.
8. There is no single point of contact for product-specific knowledge on the customer side
Sometimes there is one person on the customer team for all product knowledge, sometimes there are a bunch of people, and sometimes none. While the first case is ideal, the second case is manageable, the last case is to be avoided.
If the customer team cannot spend time on product queries, one way to tackle this is to identify an internal person responsible for product knowledge and let her spend time with the customer team for requirements understanding and documentation.
Action item: Any and all requirement discussions need to be documented and ideally signed off by the customer. Lest the deliverables should spring surprises.
9. Majority of your team members are juniors
A team is like a pyramid. There are initiators, maintainers, and closers (if there are such words, but you get the gist). There are also experts (at the top of the pyramid), people who are experts, who in turn supervise, help and mentor junior team members.
This arrangement is helpful in many ways,
(a) reduces project cost (compared to billing structure)
(b) builds expertise and experience internally
(c) builds workforce in a cost-effective way
..amongst others.
Action item: If hiring technical experts is out of the question, the project manager must at least get experts from other teams on a part-time basis to be part of the team (with specific responsibilities, and not as a favor). The project sponsor can help here.
10. Testing is either not done or very weak
In my view not having a testing team is much better than having a weak testing team/process.
I know it’s a bold statement.
The fact is that there is a tendency to consider testing activities as catching-net for bugs and this tendency leads to complacency. Not having a testing team puts the onus on the engineering to produce code that simply works.
For the same reason many startups DO NOT have a testing team (tighter budget is another reason). A developer/coder is completely responsible to deliver defect-free code that is integrated and works well with the rest of the system.
Having said this, it is not always possible to have it this way. Quality assurance and Quality control processes are necessary and they need to be viewed the right way. As ASQ states, “The ‘cost of quality‘ isn’t the price of creating a quality product or service. It’s the cost of NOT creating a quality product or service.”
Cost of conformance (prevention costs such as training & time to do the project right; and appraisal costs such as testing & inspection) are best given more consideration in order to reduce the costs of non-conformance (internal and external failure costs).
Action item: Irrespective of form and arrangement, mechanisms to ensure quality must be built into the engineering process.
11. Customer does not give ANY feedback on deliverables
This can be a ticking bomb. I have witnessed ugly situations by considering the silence of customers as a sign that all is well.
Getting into the customer’s shoes, their priority to give feedback on deliverables might be lesser than other work that affects their business. So the onus is on the project manager to get customer feedback in time so the impact on future timelines is managed.
Action item: the best way is to involve someone from the customer side throughout the development cycle and proactively give them the status of the project. Keep them interested in what is being developed and seek informal feedback. This also largely depends on the rapport developed by the project manager with the customer.
12. The project is complex and there is no architect/designer in the team
Top talent is expensive and harder to get and retain. Repercussions are quite obvious and if checks are in place then the impact will be immediate.
The remedy is to highlight possible impact proactively with the sponsor and customer (only if relevant) and get technical experts involved. Cost savings are not to be encouraged at the cost of not having the right technical leadership.
13. Customer has not paid for more than a quarter
Sometimes (and in some organizations) project manager will not be in the know about financials. Even if engineering is doing a great job and making quality deliveries on time, customers may not be in a position to pay. The reasons could be many, but it is not a healthy sign.
Account managers keep a tab on this and might decide to take a few measures on the engineering side, to offset financial impact. Such measures might mean testing times for the team (for none of their fault) and the project manager has to make sure that the morale is maintained and team members are made comfortable about their next assignment.
14. Expectation from each team member across the hierarchy is not set
Action item: Project organizational charts and position descriptions are the responsibility of the project manager.
Each member of the team needs to understand their role, responsibility, authority, and expectations – upfront. The RACI matrix (tabular chart showing individuals Responsible, Accountable, to be Consulted, and to be Informed for each project activity) also helps team members understand expectations from them.
15. No one really understands how the finished product looks like
This may be an indication of not translating detailed requirements into finished product features. This might be also an indication of not having clarity on product requirements. When they are missing, there will not be specific use cases and corresponding test cases.
Action item: “Where is the product manager?”
16. Important skills are lacking and no training is in place
Training is often not given importance and is looked at as Cost.
Spending on training is actually an investment. Irrespective of how it is done – classroom, on the job, pairing with seniors, group mentoring programs – training for critical skills required on the job is a must.
Action item: If critical training programs are missing it needs to be raised as a risk and added to the risk register. When this is done, the mitigation steps are thought through and might lead to the right actions being taken.
Well, these are 16 signs one needs to look for in a project environment.
Before getting involved in a project if it is possible for you to identify any of these – well and good. Great, in fact.
If you want to take up the project as a challenge, see if you have the authority to change things, and do so. If not and if it is possible to walk away, do so.
The outcome will surely impact your career.
Guard against unexpected project closure: Reasons for project failure
Let this infographic be your guidepost for day-to-day decisions. Download and paste it at your work desk. Let this act as a guidepost for some of your day-to-day decisions.
Here’s the infographic courtesy of Wrike – an award-winning collaboration and project management software.
Wrike lists the following reasons for project failure –
- Incomplete project requirements
- Not recognizing the risk of the project
- Not managing risks proactively
- Poor leadership
- Ignoring alternative solutions
- Not learning from mistakes
- Difficult stakeholders
- Insufficient resources
- Poor team morale
- Distractions
Wrike Project Management Software>
Which one of these would you agree with? Let me know in the Comments below.
