Best Practice: If Nothing Else, Honesty Is Just More Efficient.

Honesty is efficient: Just report the status of a project as it is. If things are late, it will show things as late. If things are confused, it will show things as confused. Spending valuable time making things look better on slides than it does in reality is not productive. It does not really help either the project or yourself. Of course, do show how you plan to fix it!

Start By Managing Well, Even If The Project Is Not Going Well

On my first project for a Fortune 50 manufacturer, I had the responsibility of project managing the overall development of a large chunk of the product software. Each month we had a meeting with the corporate VP to provide an update on how things were going and what problems needed help.

Since I was regularly (daily and hourly) rolling up status and results of our progress into Microsoft Project as a normal part of doing my job, it took me all of 20 minutes to update the overall status of the project (schedule, costs, issues, dependencies, etc.). So these meetings would not be too difficult. Or so I thought.

Don’t Get Too Caught Up In What Others Are Doing.

The other software subsystems of the product I discovered were spending days, and sometimes weeks, putting their status presentations together. They were going through a series of internal reviews to develop the status slides. Words, dates, and costs were constantly being “tweaked” and constant calls and sub-meetings were held with development managers to get additional information and agreements.

It is important to understand that this was a product that was very rapidly going very wrong.

Start Out With Honesty, Even If Things Are Less Than Perfect.

The first month I presented our software project management status, we were about 30 days late. The general idea I presented was we just had not gotten started fast enough but we should be able to catch up. The other subsystems reported they were within a few days to a week of the schedules and they were fine. That was a little puzzling as they still needed stuff from us that we had not given them yet and we needed things from them they had not delivered to us.

The second month I reported that we were on order of 60 days late against our major internal milestones for that period. I explained we had now gotten fully staffed, organized and developing and we should rapidly make up time. The other subsystems reported they were still within a few days to a week of their schedules. What stood out was their plans did not look like the ones they presented the previous month (or what I saw as I worked with them every day). Also, I had still not delivered nor received the key components we needed to exchange to hit our milestones or for them to hit theirs.

Jump to the fourth month. I was reporting triple digit slips. Being new to this company and recognizing it had a great worldwide brand name, I just figured that this must be the way it worked here. A slow start and then great progress by great people towards the end. The other subsystems were reporting they were within a few days to a few weeks of their schedules, which no longer looked anything like the original ones. It was fairly clear that the software project management tool was being updated to look like whatever the remaining schedule was. Looking around the table, I wondered what everyone was thinking and how they were going to recover. I also wondered if the corporate VP was fully aware of what was going on. He however listened hard, considered everything seriously, asked a lot of questions and extolled them to keep at it and have the product ready when promised.

Stick With Brutal Honesty, Even As Things Get Worse.

At five months out, we were no better off than we were the previous month. In fact, we had not achieved a single major milestone required in these first five months. When I got up to brief, the corporate VP ruefully laughed and said “OK now tell us where we really are!” All the other subsystems were reporting that they could still finish up everything and deliver as needed at the six month point and be ready for testing.

It was very clear that the product was either started too late for when it was needed or was planned with very optimistic assumptions. What was surprising was not so much the continually optimistic spin on the progress, but the huge effort everyone was making to produce that spin. The number of meetings and the number of revisions of the status slides were amazing.

I know this not so much because it was being done with my status (it wasn’t) but because I was being called into these other meetings. I finally concluded that organizationally we were in a state of denial. Or at least, we would never admit there was a true problem. We went through all the normal emergency responses one would do when faced with a crisis. Out of those responses we would always produce a new view that suggested all is not lost, and it IS possible to get everything done in the remaining time and be ready to test.

In fact it took another six months to get to a point where we were ready to test the software. We then spent the next nine months testing and saying almost daily “we’ll ship next week!” (Which is a lesson learned for another time.)

Avoiding Honesty Does Not Help Anyone And Just Makes The Days Longer.

Setting aside a further analysis of the fundamental problems of the organization, one of the simple ways to help avoid all this was to simply report the progress against the agreed software project management plan. The corporate VP had the ability, I believe, to ensure that this would be done by the other subsystems. Doing this would also have allowed everyone to equally admit things were not going well. I don’t know if this would have helped this product come in on time. I doubt it in this case. However, it would have saved countless hours for many people. We seemed to expend the prodigious management capabilities of these people on the spin rather than on the task at hand.

See How To Get Honest Reporting

The fact that I got away with presenting my data objectively is still a surprise to me. While I managed the subsystem for “my” VP, I only reported to him on a dotted line basis. My real boss was within the Program Management Office. The reason this office was set up was to improve our product life-cycle management. One way to do that was to make the project managers independent of the development organization. We were to be the honest brokers, but it appeared that I was one of the few to stick with it once things got tough.

Honesty Will Be Remembered, Even After A Less Than Perfect Effort.

Most of these development VPs moved on or left after the product was shipped. Many years later a more senior manager asked me if I had heard from the VP I had worked for and recalled how he was impressed with this VP’s honesty and courage during this very tough new product development. This was not quite how I had remembered things. My VP was notably unhappy with what I was doing but to his credit never directly told me to do otherwise. I think he just wanted me to figure it out and fall in-line with everyone else. So I asked this senior manager about what my VP had done to earn his respect. He said it was specifically in having me present our real progress each month rather than spinning the status like everyone else did. I didn’t say anything more, but realized he was right. It had required integrity and courage for my VP to not shut down our very efficient and brutally honest reporting.

Brutal Honesty Can Make A Huge Difference In The Success Of A Project.

Years later I was able to gain enough influence over another large product launch to put some objective and efficient honesty into the plan and the plan execution. This resulted not only in our first and largest on time product launch (as attested to by our customers – one of the better indicators of success) but it also cascaded into a series of follow-on on time product launches built against this software baseline. This now very mature baseline is still in use today as of this writing. It has outlasted many newer baselines that unfortunately never got the chance to succeed because, I believe, they were planned and managed without the benefit of the brutal and efficient honesty needed to overcome the management culture in this organization.

Best Practices.

1. Honesty is a very efficient business practice as well as a good practice in general for all those reasons we already know. Try it – it can be quite liberating for your project and startling to others in a positive way.
2. It is just too easy to move down that slippery slope of just bending things a little. I’ve worked with folks who would, in a pinch, just make things up to cover themselves and then try to stare down or make uncomfortable anyone who questioned what they said.
3. It is OK to put things in their best light. It is OK to not bring things up that would only confuse or distract folks. The trick is to judge when it is honestly appropriate to do so.