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.
No comments:
Post a Comment