Leadership

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?

9 comments
libraG
libraG

I've been experimenting with various collaboration tools and have discovered an excellent site. It is a very user friendly, web-based application that is well worth taking the time to explore. Take a few minutes and look at Projjex.com. The tutorials are excellent & you don't need to be a Rocket Scientist to figure out how to use it. It even offers a free version so you can try it on for size.

mikifinaz1
mikifinaz1

I was working as a consultant and the company rep wasn't looking to actually have the project work but looking for some one to blame. I made the project work and the rep got fired. Beware of the elusive.

donstrayer
donstrayer

I learned through similar bad experiences that the key to communication is to speak their language. Describe things in terms of their frame of reference and do not assume that they know anything about your technical frame of reference, unless you know for a fact that they do. The problem here was that Frank did not understand how far a mock up or prototype was from the finished product. In his mind the detailed design, programming and testing was probably little more than editing a rough draft. To an engineer or an architect, describe the prototype as an initial drawing. To a business person, describe it as a "straw man" process model. They'll understand that most of the work remains to be done.

lucas.palmisano
lucas.palmisano

It is important to be clear at the role of each memeber of the project team. also is important to have totaly support of your direct supervisor otherwise you have to managed the entire project stand alone way that means your project is doomed to fail.

PM Hut
PM Hut

From what I've read, it seems to me that your boss was playing the role of both a Functional Manager (eg. IT Manager) & Project Manager. Usually this leads to no accountability whatsoever from the Project Manager. In this article: http://www.pmhut.com/most-it-projects-fail-will-yours there is a mention that one of the reasons that lead to IT project failures is lack of accountability. I am wondering though, how did you get the project done, did your company replace your boss immediately with a better boss or were you an interim for a while?

tim
tim

It's not just software project delivery dates that can be elusive. Any tech project such as an upgrade to GigE, replacing a server or upgrading to Exchange Server 2007 can involve multiple vendors and shared responsibility. If you are the IT Manager and use outside vendors for delivery and installation of new technology, it can be a major juggling act to make sure all components get installed in the correct order. But the responsibility is still yours to make it happen on time.

SObaldrick
SObaldrick

To keep the PMs honest. I would not work for a PM who could not show me a workable project plan, with feasible delivery dates. Leslie.

tim
tim

Thanks for the link to the great article on pm.hut. That is a comprehensive source for analyzing project management failures. I had never been there before. The article states that 75% of all projects are considered failures by those who initiated them. Wow! That's an eye-opener for me. Here's how the project got completed: When Frank was invited to 'move on', the management of the project was given to a now-promoted co-worker, a CPA who understood much better than I did the complexities of trying to create an inventory control and billing system. He was a great manager. Why was he a great manager? The CPA could talk to the business owner and to me in ways that my previous manager never could because he was a sales guy. With just a few short meetings, the project was scaled way back, milestones and deliverables were clearly identified and daily reports were initiated. Although he was not a programmer, Mike, the CPA, was a down-to-earth kind of guy who was into technology. He and I related well. I would come to him with what I thought was a major obstacle, and in just a few minutes he had either suggested an alternative approach or the 'feature' I was trying to add was soon removed as an initial requirement. In short, as I hope I pointed out in the post, good project management requires good communication. Salespeople are great in getting something started, but don't let them manage complex technology projects. There is a real skill to project management as I soon observed from a pro who knew what he was doing. Thanks for asking the question, PM Hut. Your site deserves a more frequent visit. I see there is a huge world to professional project management. I may have stuck with my programming career if I had been exposed to the great body of work found on your site but then, the web didn't even exist when I was programming back in the early 80's.

PM Hut
PM Hut

Hi Tim, Thanks a lot for your answer. It is impressive to know that although he wasn't a programmer, he was able to help you overcoming major obstacles.

Editor's Picks