Program Guidance to Start Successful Project
Let me be perfectly clear, I hate PMOs. It matters not if you call them project management offices, program management offices, or portfolio management offices, they only spell one thing—poor leadership. Now those of you that know me, have heard this enough times that your eyes are rolling back as you mumble, "Here he goes again. Who set the bait in front of him this time?" However, I have confused people with a couple of PMO articles that might seem contrary.
A project's destiny is set very early, often before the project even starts. A properly run project launch is the first opportunity when all of the key project stakeholders are gathered and can identify and correct issues. Critical to the kickoff's and project's success is having the right stakeholders reviewing and agreeing to the project approach, risks, and mitigations. Without this short alignment workshop the incident of project failure is much higher.
Project Launch Benefits Include:
- Set up the project for the best chance of success.
- Define the proper project approach through prototyping solutions.
- Identify and vet major project risks.
- Assess mitigation strategies.
- Determine contingency requirements.
- Attain consensus on roles and responsibilities.
Prior to signing any contract or statement of work (SOW) it should be reviewed by your legal team. While legal experts understand legalities that will helpful in court, they are not delivery experts who can determine whether a SOW will provide you with the product that you anticipate, need, and desire. This review will analyze the scope, methodology, deliverables, and proposed cost to identify for areas that point to weaknesses in the ability to deliver or misalignment in intentions that could result in project failure.
SOW Review Benefits:
- Demystify the SOW.
- Get more value from your subcontractor.
- Minimize risk and vulnerability.
- Save money by avoiding risk.
- Eliminate ambiguity.
- Understand and resolve the gaps between the contract and SOW.
- Identify what is missing that should be added.
- Proactive, Preventative, Productive.
Tired of doing the same thing and expecting the different results? The goal of a properly run retrospective is to do more of the good things and fewer of the bad. Even well run projects have lessons that we can learn. Preforming a retrospective on a project allows you to capture the highs and lows of a project and integrate that information into a library for others to use.
The lessons could be about handling risk, a new process for you company, allocation of resources, or a multitude of other data. Without discussing and capturing that item, you are left to reinvent this wheel or stumble in the same hole in the future. Objectivity, experience, and an unbiased perspective are key for conducting a value-laden retrospective that solves problems instead of looking for blame, and that complements team work over the individual hero. It takes an experienced outsider who is removed from the history and politics to see the issues and make the recommendations that will maximize the lessons learned.
From her corner office, the new executive decried, "Decentralize the PMO. Let each department be responsible for their own projects." Maybe she had made a pact with another executive for some other bit of power, or it could be she lost a power struggle and the PMO had to go, or possibly she has little regards for project management thinking it is a mechanical, blue collar discipline that methodically follows a recipe to execute each project. Bottom line, she is missing the point of the Project Management Office (PMO)—it is all about business goals. Unfortunately, for the company, decentralized PMOs provide little if any value. They are similar to distributed teamwork—an oxymoron. The concept is illogical.
Back in the eighties, I was working for a large aerospace company cutting my teeth as a systems analyst. My bosses were a little older than I am now, and they loved talking about the days before cubicles, pontificating on how personal computers were inferior to mainframes, and reminiscing about the days of the BOMARC missile. It was their way of telling us thirty-something kids that they were in control and we needed to respect their position. Then, as now, information was king and these pterodactyls were not letting it go. To earn the stripes, one had to partake in the tribal rituals, smoke cigars during three-martini lunches, and attend your boss's parties. They saw no value in email let alone the boondoggle shop floor automation project I was part of. In two words, communication sucked.
A friend of mine alerted me to an article in a PMI Community post titled Is Manipulation Ethical? From the title, I thought this would be neat read. However, the article was pretty swallow. How foolish to think that a 650-word article would address an issue that has plagued philosophers for a few millennia. The initial reaction was to the manipulative title, which was deceptive. It led me to believe the article would supply some profound knowledge. The short treatise failed. To its credit, though, it made me think. On the second pass, I decided that I disliked the article. In fact, its thesis—manipulation is ethical—is morally wrong.
Last week I gave a presentation at the San Diego PMI Chapter's Tutorials conference. Flanking both sides of my ten o'clock presentation in the leadership track was Steve Romero. His two presentations were on IT governance. His energy, insight, enthusiasm, and passion (not to mention being the IT governance evangelist for CA Technologies) made him an excellent selection. And, what is so news worthy about that? Nothing. However, for someone that has little regard for adding one more layer of management to solve a problem, I was surprised that I sat through both of his presentations. He provided a three hours of information on governance—both PMOs and PPMs—crammed into two intense and valuable hours.
Businesses exist to make money. To improve operations they create various initiatives with promises of improving the bottom line. Projects, though, cost money. They do not make a profit. The dichotomy in a strapped economy to spend savings on projects to improve future profits usually results in the conservation of cash. Many an argument has been had over whether it is better to run improvement projects, burning precious cash and heading off the competition, or taking the traditional approach and wait for times with better cash flow. Subsequent to 2008's financial folly, it is well known that most companies sat on their reserves and waited. That action may have some unintended consequences that are in the midst of surfacing.
Few events start a project manager's day off worse than a yellow sticky note on his or her monitor saying, "The finance manager would like to talk to you." An email is equally as bad; however, the note at your desk means that someone actually hunted you down looking to talk about, you guessed it, finances. There must be some problem. Everyone knows the finance folks would never wander into project-land to invite you out for a friendly cup of coffee. You quickly review the project's finances. Everything seems in order. With a sigh, you contemplate whether you should walk over and see her or will a phone call be the least painful option? Yes, painful. Anytime the finance manager calls, there is going to be a lot of new work.