Saturday, January 26, 2013

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.

Saturday, January 19, 2013

An Interesting Article on PMOs

Recently, a colleague forwarded an article to me that appeared on Information Week. The article title was "Project Management Offices: A Waste of Money?" (November, 12, 2012). The author, Jonathan Feldman (of whom I corresponed with and spoken to) suggests
that establishing a Project/Program Management Office (PMO) carries with it great risks. Among those risks are increased IT costs, as well as a lack of significant improvement in processes. Jonathan was reporting on a study from the Hackett Group that looked at more than 200 organizations. Jonathan was kind enough to agree to a discussion and when we spoke about this, I stated that I agree with the study findings that if a PMO does not align itself with the strategic vision and values of the organization, it may very well fail its purpose.
Our discussion 

When we finally had a chance to speak at greater length, Jonathan mentioned several findings from the study that opened my eyes.

- The average lifespan of a PMO is under four years:
This is a shocking statistic, but the more I thought about it, the more it made sense. A PMO is not a silver bullet that delivers positive results just because an organization puts one in place. Similar to any strategic initiative, it must be well defined and thought out. If it is treated like a fad, then it will become a fad and fade out.
- My next question was "is Agile better suited for smaller organizations:"
Jonathan suggested, based on study findings, that this is a resounding NO. I will admit in full disclosure that I have not worked in a truly Agile PM environment. I will also admit that I was shocked that this study found that in some cases, implementing an Agile process produces better results than implementing a PMO. Jonathan stated that the reason why Agile may succeed where a PMO does not is because there is less overhead.
- Our next agreement was that some organizations plan to fail:
One of the things that Jonathan and I agreed on right away is that one reason Information Technology (IT) PMOs may fail is because in PM practices, there is planning and forecasting for a period of time that is unrealistic to plan and forecast properly. In other words, some PMOs engender lying because forecasting too long for a specific implementation may be unrealistic.

Business driven, nothing more, nothing less
Even though I have stated this before before, it is worth repeating. The PMO must be focused on strategic projects that are driven by the executive office: the C-Level Executive Suite, or as Jonathan put it, “the C-Suite.” In other words, projects must be business driven. That is why I am a proponent that a PMO should be an enterprise-driven group and could have projects that are not IT projects.  Whether their purpose is to improve the core business of the organization, or to enhance a product, or to improve a supporting process in a business, projects must be aligned with the strategy of the organization. In his article, Jonathan mentions that if a PMO is put in place and is only given lip service from the C-Suite, then the PMO is doomed for failure, as is anything that an organization implements without the correct support or resources.
                                                                A paradigm shift?

I hope that you understand that I still believe that a PMO that is properly implemented and supported by senior management can be successful. However, like any trend, it can be implemented for the wrong reasons, and have the wrong individuals running it. A properly supported and implemented PMO can drive an organization to excellence and have the organization speak as one voice to its clients. I am convinced that the PMO structure is a successful business strategy.
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.

Saturday, January 5, 2013

Should the Project Manager be on the sales call?

I can hear the resounding YES from all of the Project Managers (PMs). We would love to be on the call so that we can correct the misstatements and confirm the scope before the project starts. I can also hear the resounding NO from all of the salespersons. Sales is supposed to do just that— sell—and if a slight exaggeration is used to get the sale, so be it.
We all know the arguments, but let’s look at the positive and negative effects from both the PM’s and Sales’ point of view. 
The Sales Perspective
From a Sales perspective, there may be more negatives than positives for the organization if the PM is on the sales call. Does the PM really want to contradict the salesperson in front of the client? This could do irreparable harm to the relationship that the salesperson has worked hard to attain with the client. This also could make the PM look bad in front of the client. If the client has a close relationship with the salesperson, the client could be thinking that the PM is not a “team player.” If the salesperson is successful “going rogue” regarding the product or service and takes “liberties” on the benefits of either, the PM could step on the toes of a successful salesperson. Who do you think the salesperson will call first? If the PM is lucky, the PM’s manager will get the first call. The salesperson may call his manager, or worse, the executive manager of the sales team. These are negative consequences that the PM must now rectify. Also, at the next sales and PM meeting, that salesperson can use his or her clout and make that meeting very uncomfortable for the PM and the PM’s manager. This damage may take a long time to repair, especially if the sale does not go through because of the contradiction by the PM.
So, how does the PM or the PM group handle this salesperson and others like him or her? This goes back to my article on “Fostering Partnerships in Professional Service Organizations (PSOs).” This can lead to a learning experience for both organizations. With this education, professional relationships can be forged. As I discussed in that article, a meeting between the two groups is necessary and beneficial for both groups.
There are also positives that could be presented here. If the salesperson and PM have a good professional relationship, the salesperson would bring the PM to help “qualify” the sale. This only adds to the client relationship in that the client sees a collaborative effort between the salesperson and the PM. The more comfortable the client is, the easier it is for the salesperson to “discuss” other services and products that will lead to additional projects for the PM and the PM Group. 
The PM’s Perspective
Let’s face it: we want to ensure when we kickoff a project that the scope of that project is already understood by the client. It is imperative that the PM establishes this fact so scope creep is kept off the radar. However, when the PM hears questions about scope that were not discussed prior to the kickoff, the PM has a right to be upset.  It is the salesperson’s responsibility to qualify the sale prior to handing a project to the PM Group. This may mean an educational process for the client. Most salespersons do not want to do this because of the time it takes to do this properly.  However, if a salesperson is consistently handing off projects with misunderstood scope, then Sales and PM management have to have a discussion about sales education or a discussion regarding the specific salesperson.   
The first step a PM should take is to discuss scope at a kickoff meeting with the complete project team. This must be done methodically and specifically and define what is in scope and what is not. During this discussion the PM must be prepared to react to confusion, anger, and even resentment. The client may have agreed to a different type of project that what the PM has presented. The PM must have the signed contract or SOW as part of this kickoff. However, the PM should not use the contract or SOW as a tool of “I told you so” retribution. What the PM should be doing is using the contract or SOW as a tool for explanation to the client. There is an opportunity here to prove the project team’s worth by ensuring that client needs are met, even if it means a change order before the project starts.  The PM must be able to obtain agreement from the project team and to let the client present any changes to their senior management as well as the PM’s senior management.
Sales and the PM team must be able to meet in the middle regarding any difference of style and be able to educate each other during this process and each mission going forward.  
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.