The first week out of college in my first job people told me, "No surprises on your projects." I had no idea what that meant and struggled with this concept of surprises on projects for years. I eventually learned what people were trying to express and a few techniques that helped with warnings about bad news.
Surprises on projects? What were people trying to tell me? A surprise is something unexpected or unanticipated. My managers had been working on projects longer than I had been alive. At least it seemed that way because they kept telling me long stories about projects they worked on before I was born. Their projects were filled with tragedy and a few rescues and triumphs. Often they were chastised by their managers by bringing news of impending failure.
If these people had worked on so many projects for so many years, how could I surprise them by what happened on one of my projects?
After years of projects and listening to managers talk about projects, I finally understood the prohibition on surprises. "No surprises" meant, "don't tell me bad news unless I have time to act on it and change the course of the project."
That made sense. Now I had a clue of what I might do while managing projects, but I still wondered, "When do I present bad news?"
No matter when I brought bad news, my managers reacted the same way. They chastised me and asked all sorts of questions. "Why didn't you do this? Why didn't you do that? What were you thinking? How did you let things get out of hand?"
I didn't know the answers to any of these questions. I felt uncomfortable and stupid.
At times I wondered about not telling my managers bad news about projects. Why should I worry my managers and endure their endless queries? Perhaps the projects would correct themselves in a few weeks. I often held the bad news for a while to give the projects a chance. That strategy never worked for me. Bad news only became worse and resulted in yet one more question, "Why didn't you tell us about this a few weeks ago?
So I learned to tell my managers bad news as soon as I knew it. I struggled, however, because I never knew the bad news soon enough. I passed on the news as soon as I knew it, but the projects still failed. Something was still missing.
One thing that helped was a leading indicator. That pointed to problems coming for the project. Most of the time, the leading indicator provided enough warning. Simply, "The trend is bad. If this continues, the project will fail. We need to change the situation now!"
The most reliable indicators measure actual versus expected progress. If we thought we could accomplish an amount of work in four months and we needed five months to do it, we needed 25% more effort than we expected. A ten-month project would take 12 or 13 months unless we changed something.
That type of measure made sense, but it had its problems. First, we had to have planned and estimated the work. That was a lot of work in itself. Second, we didn't always have that simple, clean measure that told us we were 25% behind. Calendar time wasn't always the right indicator. Cost per week, turnover of personnel, changes in requirements, effectiveness of reviews - different measures indicated different things on different projects.
I wish I could now come to the punch line and write the one measure that provided enough information in enough time to prevent "surprises." I cannot. I can provide a few suggestions.
(1) Talk to everyone everyday.
Troubling trends aren't always in the numbers. People often have a feeling that things are just not right. Those feelings can lead to changes that help.
(2) Collect and analyze information on cost, schedule, and performance.
These are the classic comparisons of expected versus actual. The performance category includes many factors of quality - too mnay to discuss here.
(3) Invite outsiders to look at your project.
I can look at my projects so long that I become blind to the obvious. I don't like answering "why," "what," and "how" questions from outsiders in the middle of a project. That feeling, however, pales in comparison to the anguish of similar questions from managers when a project fails.
(4) Try to be honest with yourself.
I take great pride in my projects and my ability to manage them. I have worked hard, learned much from many experts, and used my best judgment. Nevertheless, my efforts are not always good enough. The hardest thing I attempt is to step back, reflect on my performance, and provide an honest assessment of my own projects.
These suggestions have served me well, but they haven't worked all the time. I suppose there aren't any "work all the time" techniques out there. If there were, that would be a surprise.