Ramon Ecung's Blog

I used to work at MD Anderson Cancer Center where I developed web applications. Part of my job was to directly interface with customers and take their requirements and develop them into finished products. Our team of developers each had their own projects to work on, and could decide if they wanted to interface with the clients or if they wanted the project manager to be the intermediary.

I decided to manage my own projects so I could understand the clients needs directly and so I could bring up ideas or technical issues that the clients may not have known. Talking with the stakeholders directly made developing the scope statement very easy because I could take their needs, formally write them up, and document what the project was.

A scope statement is a very necessary part of a successful project. While working on a project that I inherited from the titled project manager, I developed an application to the specs that he verbally told me. He later got a promotion and when I started talking with the stakeholders, 80% of the features I had developed were “cool” features that were functional, but did not meet the needs of the clients. If I had a document to work from that was signed off on, there would not have been any surprises and there would be accountability for project failures.

I believe the old project manager had a philosophy of “passing the buck”. I had asked him a few times to send me requests via email, or to get some paperwork signed by the stakeholders so there would be no surprises, but he wanted to not be accountable if the deliverables weren’t done by a certain date. This is a completely inappropriate attitude for a project manager. First, if the deliverable isn’t completed on schedule, it’s the developer’s fault, not the project manager’s. Second, the goal of a project is to provide a benefit for a business and taking it to such a personal level undermines the business’ best interest.