Congratulations, you’re a project manager! The investment team has already set the budget, schedule, and scope of your product development project. The executive staff assembled the project team.

Like any catastrophic failure, errors have already been made by multiple parties, well in advance of the events that will ultimately expose the failure.

Now, they will watch and pray.

All of the following are true scenarios I’ve encountered at least once in my career, or I know someone who did.

27 Signs Your Project Is In Trouble

Scale Issues

1. There are 17 inter-related work streams, the projected budget is 10x the biggest project ever undertaken by the company, and the schedule estimate is 36 months.
2. Your $14M project is a loss leader on the system integrator’s $800M multi-year product, services, and management consulting agreement.

Team Life Cycle Issues

1. The executive team hired the project manager after the rest of the team.
2. The team has worked months or years without a project manager or scrum master.
3. Two weeks before product release date, the Software Development Manager gives notice and leaves the same day.
4. You’re replacing another project manager on an initiative that’s been underway for a year.
5. The Product Manager, who’s been with the company for 8 years, says he’s all about new product development. Everybody knows the company hasn’t had a revenue-producing new product release in 8 years.
6. I once worked at a place with 300 employees and 270 “critical initiatives.”
7. The former project manager experienced a work-related nervous breakdown.

Technical Fiascos

1. The data integration relies on middleware and database features in the system integrator’s products. Those features won’t be delivered for 18 months or more.
2. The contract calls for product release in 12 months, and the software development team reveals two work streams that will each take 18 months to finish.

Work Breakdown, Estimation, and Scheduling

1. The software development team won’t break down or estimate any work in less than two-week increments.
2. The software development team has chosen to use strict Kanban delivery methods despite a hard delivery date and refuses to provide a detailed work breakdown.

Requirements And Scope Management

1. “We’re just going to re-implement an existing system…with a few changes.”
2. An executive of the customer’s company set the schedule and budget from the golf course, and his source of truth was a consulting company executive in the next golf cart. “We can build a system like that for $8M.”
3. The product manager refuses to write product requirements or business rules. “The Software Development Manager already knows them.”
4. A critical subsystem has no documented requirements.
5. The product is “groundbreaking”. “Nothing like it has been done before”. The executive team is thrilled: they hired a software development team who’s built a similar product!

Communication and Alignment

1. There’s a perception among executive staff or throughout the organization that your project is in trouble.
2. The CTO asks you to help the software development team define a schedule, then the Software Development Manager threatens to quit.
3. The Software Development Manager threatens to punch you in the throat.
4. Your role is to manage testing a software product that’s been under development for a year. The User Acceptance Test (UAT) owner’s mantra at steering committee meetings is, “I can’t put this $#!7 in my store”.
5. A critical subsystem developer is a contractor with teams in two different countries on another continent. They speak a different language than the team that owns requirements.
6. One week prior to release, the Software Development Manager announces a previously unmentioned vacation. He’ll be unavailable by phone or email.
7. Your boss and account manager say they’re too busy with other projects to support you on yours. “Sorry, you’re on your own”.
8. Your customer reveals they sued your company for breach of contract.
9. Your company can’t figure out how to add 3 free staff members to the project.

In tomorrow’s post, I’ll share how to manage these situations.

Consider And Act

• Assign yourself 1 point for the above items that are true for your project. If you have 1 point or more, your project is in trouble. Should you begin project recovery, or do you need a priest?
• What other examples do you have of project trouble indicators? How have you resolved them?

Share

Share advice, information, or referrals on this topic in the comments box below. I appreciate your contribution and will use it to improve!

Connect

More About Me And This Blog

Contact Me For Help With This