Project management responsibility can be elusive

When two or more people are involved in delivering a technical project, there is an absolute requirement for shared responsibility if the project is to be successful.  This means communication.  It also means that understanding of that communication is essential.  In other words, you have got to be sure that the message you are trying to deliver is being received.  If you fail to agree and understand each other as a team then your project is doomed to fail.

In two previous posts I introduced the story of my first programming project.  In the first post I described the initial meeting with the client in which the engagement of services document was signed.  In the second post I shared what for me was an epiphany in my career - not all people and especially not all managers think like computer technicians.  In this post I would like to explore the idea of shared project ownership.

The project review meeting from hell 

My boss finally realized that he was not going to be able to deliver the finished project in the amount of time he had quoted the customer.  Not only had he disappointed the customer but he was in trouble with his boss.  He began to rip me up one side and down the other as he poured out his frustration and disappointment on me.  It was an awful experience and I’m not sure how much of it I deserved.  It all stemmed from assumed expectations.

Finally I could take it no more.  I almost shouted as I interrupted his tirade.  “Frank!  You never asked how long it would take when we started.  If you had asked I would have described the steps involved.  You only saw the initial mock-up and the secondary prototype.  Those only take a few hours to complete.  If you knew anything about programming you would realize that it can take weeks or months to make the real program work.”

Of course, Frank really knew nothing about programming.  What I didn’t know was that this wasn’t the first time Frank had promised and not delivered.  He was soon fired for not having a firm grip on reality.  He had apparently gone through a couple of other techs before I came on board.  I got the advantage of learning right away in my career that I need to do a better job of communicating with non-technical types if I was be successful.

Results of the boss being fired 

Did I feel bad that Frank got fired?  Of course I did, especially since he had hired me and had sold me to the owners of the company as someone who could create wonderful programs that would meet the needs of their customers.  I had provided samples of my work in our interview but he had never asked how long they took to create.  If we had discussed and understood this small detail then things would have turned out very different for Frank.

Did the project ever get completed and delivered?  It did indeed.  I began to work more directly with the customer and soon learned that he didn’t really need all the bells and whistles I had in mind when we first discussed the assignment.  The project scope was cut way back.  He got what he needed shortly after Frank’s departure and I went on to do several other database-driven programming projects for other customers of the company.

What did I learn from this first project?  I learned primarily how important it is to communicate on the level that the others involved in the project can understand.  I also learned to take some additional responsibility for project management that I had previously assumed would be handled by the sales guy.  I clearly learned how important agreed-upon milestones and progress reports are to the success of any project that goes over a few days.

Bottom line: learn to communicate better 

You see, it doesn’t matter if you have a vision of what you think needs to be done if you can’t communicate that vision to others, especially your own boss.  As this example illustrates, it is extremely easy for others to get a false impression about something based on first impressions.  You may think it takes more effort to explain your vision to someone else than it would be just to accomplish the project and show them, but if it is a shared responsibility it is an absolute must.

What do you think?  Is shared project management responsibility an issue in your organization?  Do you ever find yourself in a position where you have to deliver on a ridiculous time schedule to which you did not agree?