Project Management

“If history repeats itself, and the unexpected always happens, how incapable must Man be of learning from experience.”
George Bernard Shaw

Here’s a fictional scenario. It takes place in a project postmortem session. The product manager looks in his papers or dashboards and says something like “We had too many defects in this project”. The developers look at each other. They know anything they say will sound like an excuse. “So,” the project manager continues, “I guess we’ll have to do better next time!”

Learning from experience is not that simple. It is simple when you can easily identify cause-and-effect. A child may touch a hot surface once, but as soon as he gets his finger burnt, he will learn to be more careful next time. Cause-and-effect is apparent in this case. But life is more complicated to be described as a sequence of cause-and-effect events. And a software project is no different.

A software project is a dynamic and complex system. To start with, it involves many stakeholders: the customer, the project manager, developers, testers, the development lead, marketing, and management. External forces, such as regulations and competition, often influence the project as well. And then there are of course other projects, which might compete on the same resources. To this inherent complexity, one can also add changes in the requirements, third-party components’ failure, sudden crisis modes, and other unfortunate events.

Learning from experience means examining what happened in the project. It means analyzing what made it a successful project, or what were the problems in the project and how they could have been avoided. But this is not trivial to do in such a complex and dynamic system.

A prerequisite of any analysis process is having meaningful data to analyze. This may sound trivial, but think of the last time you had a project postmortem (or if you prefer a more positive term: “lessons learned” or “retrospect”) session on one of your projects. Chances are that you had in front of you some raw data, such as the number of bugs, the project plan, the different artifacts that were produced as part of the process, etc. But this raw data doesn’t tell the whole story. It doesn’t necessarily tell you what really happened. If you identify, for example, a sudden increase in the number of bugs, you’re probably just looking at a symptom. To really learn something useful from this data you must understand what caused the sudden increase. And the same applies of course to schedule slippage, customers’ complaints, etc. Behind all these symptoms there are people, processes, dynamics, and events, which are not reflected directly in the data generated during the project.

Fortunately, there’s a simple way to fill in most of the gaps: maintaining a project log. The project log is used to record what really happened during the project. How do you do that? Quite simply. Every member of the development team and other stakeholders as well, can access it at any time to record an event.

What events should be recorded? Anything that might have an influence on the project. When there’s a change in the requirements — log it. A crisis in a different project caused some interference — log it. An external component was buggy and support was a disaster — log it. The artificial-intelligence-enabled sprinklers system in your office decided it’s time for a cold shower without any apparent reason, and your entire team was not able to work for a week — that’s right, log it.

It might seem funny at first, but think of it: you’re probably using logs to record events in the software you create. Logging events in a software product is used for understanding what went wrong in case of a failure. The exact same idea should be applied to project management. If you want to understand the source of a failure (or a success for that matter), you must first understand what really happened — what were the dynamics that led to this failure (or success).

It’s not about making excuses or preparing a cover-up. The purpose of a project log is to provide you an additional view of the project. Trying to re-create what really happened without a real-time recording is not effective. With all the stress around the project, and the frequency of internal and external events, many things will evade you.

In one of the project-postmortem sessions I attended, one of the developers claimed that it took him a whole week to address a last-minute change in the requirements. Nobody in the room seemed to remember it this way. They were all certain that this particular change request had been implemented in less than a day. With a project log, this wouldn’t have happened. Getting your facts straight is a prerequisite for driving an improvement. If you cannot agree on the facts, you won’t be able to come up with a real improvement plan.

But the best part about having a project log is that you don’t have to wait until the project ends to analyze it. Analyzing problems after they occur is only second best to preventing them altogether. If you analyze your project log on regular basis, you will soon be able to identify certain patterns, which may be the source of potential problems. You will be able to address these potential problems while they are still manageable. You would learn to expect the “unexpected”.

There isn’t any magic about it. The project log will not provide you an answer to every question you have. The dynamics of a software project are often more complex than what you can capture in a sequential log. But a project log is a good start. It provides you a breadcrumb trail to help you find the source of problems and the reasons for successes, so in your next time you can do even better.