Last week, I gave a 2-day workshop on project management. I focused on what I call the Five Principles for Project Success. It’s been my experience that when any of these principles are violated, a project is headed for trouble. Conversely, if a project is in trouble, reviewing these principles is critical for recovery.
Everyone involved in a project at every level should always know the project purpose: who cares about a project and why is it important. People should know the project drivers (e.g., cost, quality, target date, feature set, stability, usability, performance, flexibility, accessibility, …) and how the drivers are ranked. This is the only way to rationally make tradeoffs within and across projects.
The project purpose is frequently overlooked because we tend to focus on the work that needs to be done and often get started on it without asking why. When this happens, we tend to work on tasks we want to work on, not necessarily what’s most important for the client/customer and stakeholders. We don’t move the project in the right direction, if in any direction at all. There’ll be plenty of motion, but not much progress. At some point (when the budget or schedule gets tight), we’ll have an emergency meeting to figure out what should be done and finally the project purpose will be recollected or even spelled out for the first time. Great, but too late. There won’t be room to recover.
The project purpose should be defined up front, and, again, everyone should know it. The purpose should be captured in something like a “Project Charter”. Johanna Rothman describes these charters in her book Manage It!.
The most famous quote on planning is probably from Eisenhower: “Plans are worthless, but planning is everything”. Ike said it in the midst of the Cold War, but it’s a timeless observation. When engaged in planning, we’re considering options. We think through risks and how we might address them. We lay things out, we make assumptions, we make choices. At the end of this we have a plan. However, no matter how thorough our plan or how much thought we’ve put into it, the plan can only reflect what we know at a given point in time. Things change. We may run into a set of unanticipated problems or perhaps the risks we did consider didn’t really have the impact we feared. When this happens, we should adjust the plan. We should re-plan.
Without planning, projects will be left to chance. Risks will come as a surprise and quickly derail a project. People will be constantly shooting from the hip, making decisions based on urgency instead of value, reacting to events instead of anticipating them.
Planning is something we should do throughout a project. When a plan is no longer useful, we should draft a new one. The plan itself is only a snapshot of what we knew at a point in time.
To make rational decisions about projects, you need to track project data. Period. This isn’t something you get from chatting with someone. When you ask “How are things going?”, you’ll get a response like “Pretty good. I think we’re going to be done with this next phase soon”. What does that mean? What does that tell you? When someone says something like that, I hear “We’re not done yet”. You need a finer level of status than that. You should be able to answer questions like this at any point during a project:
- Is the project running late? By how much?
- Is the project over budget? By how much?
- Which tasks can be started now? Are any of them late off the bat?
- Is the project resource-bound? Where are the bottlenecks
- What are people working on?
If you don’t have tracking, you won’t know if your projects are in trouble until the end. Key decisions will be delayed. Teams will miss important dates. The sense of urgency that should have come earlier in the project will come too late.
Tracking project data can be straightforward and easy if you have the right tools. If you set up your projects efficiently, tracking them basically boils down to logging effort left and effort spent. It can be that simple (with the right tools :-)).
Demos are the real measure of progress. If you can show something working, then you’ve actually done something. If you can’t demo anything, then you really don’t have anything of value. Demos are great because they expose assumptions. They ensure that details are looked after. They get everyone on the same page, something especially important when there are several teams involved.
If you don’t do demos, teams that can work separately will — and they’ll work in isolation. Work won’t be integrated until the very end of the project. Everyone will feel their part is on track when, in reality, much of the work is yet to come. When integration finally does arrive, it will take much longer than everyone expects. There will be unanticipated rework, cost, and stress.
Demos are something we should always plan for in our projects. They can be fun. They give people a sneak peek at something that no one else has ever seen. It’s a time for teams to get together and show off, when executives get to drop by and see progress, a time to re-sync before moving forward again.
Consistency is about predictable execution. It’s about dispatching work efficiently and having clean handoffs across teams. When you have consistency, your organization runs like a well-oiled machine. This can only happen when roles and responsibilities are clear, when processes are well-defined, and when people have the skillsets to play their roles.
If you don’t have consistency, you’ll waste a lot of time reinventing process on the fly. Tasks will be dropped, especially across team boundaries. There will be gaps in process, gaps in task assignments, and gaps in skillsets. Execution will stall and be unpredictable.
To become consistent you need to think through your processes and capture them in some form. Swimlane charts are a good tool to use here because they force you to think not only about what needs to be done, but also who should be responsible for it and what sequence the work should follow. It can be an interesting exercise to get people together to sketch out a process because it will quickly become obvious that everyone had a slightly different view of the roles and responsibilities. Getting clarity around this early-on improves consistency of execution.
These are the principles that I’ve found to be crucial for project success. Time and time again, these are what I point to when projects go wrong. Of course, there are other principles “embedded” in these five (e.g., communication runs through everything above). If you can think of a principle not covered above, please feel free to comment!