If you have been working in IT industry for few years you might have been part of at least one project that was closed midway.
I have been part of a couple of such myself.
Projects are closed for various reasons – sponsor abandoning 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.
First thing is to look out for signs.
The ominous ones.
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 ways].
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 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 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.
And surprisingly, this can be a common situation. Sometimes this may be a false positive case. May be 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 project sponsor.
3. Customer has not been involved in product definition
Consider these facts –
- Product requirements change over time.
- Project takes time to complete – from few weeks to months (if not years).
- Project must be delivered to the customer.
- Customer is supposed to evaluate deliverables and sign off the project.
- If not, the repercussions may impact revenue of performing organization.
- Project manager’s bonus (even promotion) depends on the success of the project. Amongst zillion other things, of course.
These are enough reasons to make sure customer is involved in product definition and during regular product review meetings.
Action item: yes, understood.
4. There is 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 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.
5. There is no proper project tracking tools and/or 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 project’s health.
The project manager is the best judge to identify the right managing 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 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 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 customer side
Sometimes there is one person on customer team for all product knowledge, sometimes there are a bunch of people, and sometimes none. While the first case is ideal, second case manageable, last case is to be avoided. If customer team cannot spend time for product queries, one way to tackle this is to identify an internal person responsible for product knowledge and let her spend time with customer team for requirements understanding and documentation.
Action item: Any and all requirement discussions need to be documented and ideally signed off by 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 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
Action item: If hiring technical experts is out of question, 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). 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 its 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 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 customer as a sign that all is well.
Getting into customer’s shoes, their priority to give feedback on deliverables might be lesser than other work that affect their business. So the onus is on project manager to get customer feedback in time so impact on future timelines are managed.
Action item: best way is to involve someone from customer side throughout 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 customer.
12. The project is complex and there is no architect / designer in the team
Top talent is expensive, harder to get and to 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 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 on financials. Even if engineering is doing a great job and making quality deliveries in time, customer may not be in a position to pay. Reasons could be many, but it is not a healthy sign.
Account managers keep a tab on this and might decide to take few measures on engineering side, to offset financial impact. Such measures might mean testing times for the team (for none of their fault) and 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 hierarchy is not set
Action item: Project organizational charts and position descriptions is the responsibility of the project manager.
Each member of the team needs to understand their role, responsibility, authority and expectations – upfront. 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 indication of not having clarity in 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. Spend 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 risk register. When this is done, the mitigation steps are thought through, and might lead to 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 sure impact your career.
Image courtesy: bushkov