There’s so much you can learn from a job done badly that I’ve compiled a list, which is by no means exhaustive. There are many ways a project can be dragged out, botched up, and overshoot the budget.
My engineering clients chipped in with this compilation and you can apply the following situations across all technical realms.
Let me know below: what have I missed?
- Too many clashing agendas from all the business partners
The problem is many leaders don’t use their communication skills to sort out conflicting aims before they become a problem. Negotiating and setting expectations are key.
- Too many people at meetings that don’t stick to the point
It’s pretty unlikely that a 2 hour meeting really does involve 15 people. Pick out what’s relevant for whom and only have them present. ‘Meetings’ can be just as effective one a one-to-one basis, while the kettle’s on.
- Too many meetings or lack of agenda and actionable outcomes
Sometimes the outcome of the meetings is….another meeting. Who’s doing what by when? Do they have the capability and know-how? Have you checked they have the resources? Individuals need varying levels of delegation and nothing’s going to get done if they need more from you and it’s not given or benchmarked.
- Mismatching the skill set with the role, e.g., process engineer delivering electrical deliverables. It’s like hiring a nuclear physicist as a lawyer. (Of course, they could probably blow up the opposition for you but I’m not sure it’s legal where you are).
- Lack of or incomplete scope of work
I bet you know this one: Client: ‘Here’s the job.’ 1 month later: Client ‘I forgot to add this.’ 2 weeks later…’There’s this as well.’ Then they get rankled when you mention pricing and delay of completion. Part of the issue is the way information is extracted from the client / partner. It comes down to asking the right questions. Another point is that managers may take little time out to think how lessons learned in the past can be integrated into the current project.
- Roles and responsibilities ill -defined
Team friction is often due do the scope of the project changing (see no.5 above). Roles and responsibilities shift, causing ambivalence and conflict.
- Absence of risk mitigation or contingency planning
Not reflecting on lessons learned from previous projects dulls the foresight you need to spot and mitigate risks.
- Exchanging personnel on a regular basis
Not everyone does hand overs well, and some staff don’t do hand overs at all so subsequent team members have no idea what’s what. All you can rely on is management being in the know. They’ll possibly be out of the loop on small details that can make a big difference unless they’re in close proximity to their teams. If you know you’re going to have to change people round, ensure the right people are involved when the baton’s passed.
- Lack of control of work done resulting considerable amounts of rework
If the hand is off the steering wheel, the car will end up in a ditch (if you’re lucky). Likewise, letting projects run without a detailed schedule, risk management and a more collaborative approach, results in having to backing up and follow a new road from the beginning. This adds to cost and time.
Management is sometimes leading, other times collaborating, and balancing that with knowing when to step back. .