Right the first time?

In my career as an Information Technology (IT) Project Manager (PM), I have been fortunate to work and collaborate with exceptional individuals. One of them is Joseph (Joe) Puglisi, CIO of QDMH. He also authors a blog, A View from the Bridge, to which I have a link to on this blog site. Joe recently published an interesting piece titled, “An Ounce of Prevention.” In the column, Joe mentions an old adage that there is never enough time to it right, but there is always time to do it over and the correlation of that adage to the current state of IT where getting the job or project done is more important than getting it done right the first time. As a PM, I had mixed feelings about this statement. I agree with Joe that the current state of IT promotes getting “stuff” done, no matter what. I also believe that there are some C-Level executives (Joe being an exception) that want an implementation done quickly so as to put it on their list of accomplishments. Unfortunately, this is usually with little care of how the implementation is to be done and without regard to proper funding.

Getting the funding to do it right

Joe makes a great point that sometimes we in IT spend more time, and money, to patch or fix code that could have been done right the first time. Joe also mentions that the patch sometimes actually compounds the solution by not directly resolving the problem. That point really touches a nerve with me and I could not agree more. I am sure I can speak for many individuals in saying that, at times, we are our own worst enemy by not seeing the problem and solving it. However, this starts at the beginning in acquiring the correct amount of funding to do it right in the first place. As I have mentioned in previous articles, we in IT work for the business. So how do we get so messed up when it comes to scoping and funding a project?

It begins with proper scoping, but also explaining value

We all know this drill, don’t we? We must calculate the proper time, resources, and budget that will be required to provide the client (external or internal) what they need. This should be done with the requesting client with their specific request. What the PM or the estimating party must do is include what specifically is in scope. The PM must take that and correctly document what is in scope and what is out of scope. We all know that, but do we properly inform the client what will be the value of the final product? Do we explain that with this funding, what the project will produce with the implemented product or service? I suspect that sometimes (or more often than not) we do not explain what will be the value to the client. I submit that is where it is done right the first time. You see, when the client signs off on the scope, there can be no vagueness of the use of the product or service upon delivery at the end of the project.

Now, I will also state that sometimes (or more often than not), the client does not completely divulge everything that he/she needs. Be careful here, as I am not suggesting that the client may create scope creep. I am suggesting it is an incomplete scoping of the product or service. This can be corrected with a change request, but often this is looked upon as a failure of the PM. No, this is not anyone’s failure, but an incomplete scoping of the project that the client (as well as someone in the C-Suite) must take some responsibility for. Before the scoping of the project, it must be understood that anything not included in the scope that should be is considered out of scope unless the client initiates a change request. Once a change review board approves the change request, a project can be re-baselined with the new scope in it.

No blame creates gain

One of the things I have come to believe is that proper scoping along with proper estimation is absolutely critical in creating the proper project for an implementation. I also have come to believe that, if a project misses something in the scoping, the individuals did not fail in scoping the project. They have an opportunity to re-baseline the project with the addition of scope. A culture of laying blame creates a culture of project failure. If the PM and the project team feels that they can move the project along without fear of being blamed for additional scope, that only helps the project and the end user.

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine.You may inspire a blog article. I look forward to your comments.