So one thing I should say…..if the project has been in trouble for a LONG time, over budget, multiple re-planning, role changes….there’s not a whole lot you’ll be able to do as an individual. It’s a situation where everyone likely knows the truth, it’s just a question of how best to extricate the organization with the least amount of damage possible. And that tends to be a decision made very much over our pay grade. But what do you do to prevent it from happening or course-correcting?
Having spent some years working on project implementations, I’ve seen everything….the good, the bad, and the ugly. Projects which aren’t going well are the worst…everyone is exhausted, demoralized, either running or blaming. In my experience, here are the top reasons why projects fail….
Congratulations, you’ve just been asked to lead a big reengineering project. Huge..with very significant impact and exposure. Now what?
Like many things, successful projects are dependent on the pre-work…..the work you do before the project is formally underway. This can sometimes seem bureaucratic, and a waste of time, but if you can’t answer the following questions, the team is guaranteed to struggle. I went through Rummler-Brache training…it was one of the best programs for reengineering. Continue reading
I recently met with a woman who was being asked to lead a very big project. She was losing sleep over how to best manage it, started working on GANTT charts…and asked me for some advice. Here are the three critical things which have worked well for me: Continue reading
You know those rare times when you read an article, and inside you’re thinking “YES! YES! YES!” Continue reading
One of the most important tools you have to manage a project is the “one pager”. This is the one page that everyone will look at, through the life of the project to see if the project is on track. It doesn’t fundamentally change: it gets updated.
So what does the one pager need to show? Continue reading
So what are the ways to put LL #3 into effect? Here are some symbolic things to demonstrate this to your team. They’re going to believe based on what you do, not what you say. Continue reading
“If the project fails, it was your responsibility. If it’s successful, it’s because of your team.”
When things go wrong, it can be scary. Downright terrifying. But there are ways to turnaround those projects. A couple of things that have helped me.
1. Figure out what the problem is and tackle it directly. What is the issue that got you here? Make the hard decision, and get agreement. Most projects are a function of effort plus deadlines. Usually, when projects go wrong, it’s because you run out of time. The only way to deal with time is 1) get an extension, or 2) cancel or defer some of the deliverables. Figure out which path you’re going to take, and get agreement with the parties who will be impacted.
2. Encourage honesty with your team and make sure you have the right team in the room with you. Everyone gets to contribute, but you’re the leader. It starts and stops with you. Don’t expect a decision from your team: expect them to provide you all the information you need to make an informed decision and to tell you if you’re wrong.
3. Now is the time to micromanage. When things are not going as expected or when the margin for error is nil, I institute morning and afternoon checkouts. A lot of things can change in a day. Everyone’s expected to be either in the room or on the call…most times, they show up. Sometimes you can’t afford to wait till the next day to get a status.
4. Communicate: if your project’s in red RAG status, say so. Keep it in red even when you think it’s amber/turning green. Yes, you’ll continue to get unwanted attention. But I never like to flipflop statuses: nothing’s worse than going to amber only to go back to red. It raises the question “Do you know what you’re doing?”
5. Be factual and simple in your updates: sometimes it’s email, sometimes it’s a presentation, sometimes both. Overcommunicate. I often use monthly calendar slides for team updates: I’ll show the time we have left, and I’ll have what we need to do scoped out on the calendar. I’ll put in all the major deliverable dates, buffer time (for anything that might go wrong), and most importantly, the end date. It gives a very clear depiction of what we have to do and the time we have to do it: the two variables I need the team to focus on.
Crisis management isn’t fun. But you learn the most about how to get things done by running to the fires and knowing what to do when you get there.