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.