The Art of Obtaining PMO Governance – Without the Bureaucracy

While I could fill this blog with a list of things to do and not to do, I’ve found some of life’s lessons are best communicated through stories. Here’s one of mine. Prior to joining Changepoint I worked for another company as a senior director of PMO, and I vividly remember the first time we rolled out a formal PMO department. It came after the company went through divesting half of its business followed by an equally substantial merger, forming a new corporation. We were coming out of rationalizing our business processes which included a migration to a common set of systems to support the new enterprise.

I suppose we were no different than many other companies faced with the challenge to do more with less staff and the added pressure to deliver projects at an accelerated pace. For example, each Business Unit had its own list of critical requirements, and we were challenged with capacity constraints and a fixed budget. To top it off, we didn’t have an impressive track record for delivery performance – It was clear we had to improve. Improve our speed to delivery, the quality of our work, and forecasting capabilities all while trying to minimize volatility and stabilize our throughput.

We believed the root cause of these shortcoming was how we managed the life-cycle of projects from demand intake through project closeout. If we could establish a framework to prioritize the demand, implement a standardized process throughout our System Development life cycle (SDLC), and adopt formal change control procedures we thought we would be on our way to solving performance issues.

We developed a standard SDLC process that included formal prioritization and change control procedures. Everyone in the organization supported the new process with a belief it was the right way to move forward and solve our shortcomings. Once the new processes and procedures were implemented we had a way to rank and prioritize incoming demand, and our change control procedures were now in place. However, time went by and nothing improved.

What we failed to understand was that improvements could not be made simply by putting processes and procedures down on paper and expecting everyone to follow. We did not realize the need for governance to ensure compliance, or that formal controls were needed to ensure everyone followed the new policies and procedures. I’m not sure how we missed this, particularly since we lived through SOX404.

Compensating for this required formalized audits and compliance throughout our newly formed processes. This required formal reviews with all stakeholders who had a vested interest in the deliverables with a requirement to include support material to prove compliance. As an extension of this compliance, checkpoints and formal reviews were put in place. We thought the formal signoff and approvals would ensure conformance and guarantee success in achieving our objectives, but again time went by and nothing improved.

We found the controls actually resulted in an exorbitant amount of time to prepare for and ensure compliance. To quote one of our project managers: “It takes more time to document, set up and prepare for the compliance meetings than it does to deliver the solution.” Our epiphany came when we realized that governance was actually the art of balancing formal control with the flexibility to get the job done as efficiently as possible, and that too much latitude on either end resulted in sub-performance.

Keep this anecdote in mind when you formalize your own PMO governance processes. As you continually monitor the balance of control against efficient execution, recognize that balance is not static and should be adjusted based upon how well team members are adhering to processes. The better the adherence, the less control will be needed which drives efficiencies and overall delivery performance.

Do you have a personal PMO rollout story you’d like to share?  We’d love to hear them. You can reach us on LinkedInFacebook or Twitter.

The Truth about Three Big Project Management Myths

APM, the Association for Project Management, is going to be busting the big project management myths at the upcoming APM Project Management Conference on Thursday, March 19, which got us thinking about what we think the biggest myths are, and why they are not true. Here’s a run-down of the three most regular myths I come across:

1)  You must be certified to work in PM.

It saddens me when I come across people who think that they are not going to get anywhere in project management because they are not certified. Of course it is advantageous, but from a recruitment perspective, it is not always necessary. While two-thirds of bosses told that they found PM certification to be valuable, they did not say they would not consider uncertified candidates.

2)  PM is paperwork-heavy.

It’s an exciting time for the industry at the moment, with the stream of constant changes continuing to alter the way we work. One of the impacts the development of PM software is having is the reduction of paperwork. Our industry stands to benefit from the automation of processes, and software is continuing to hack away at a considerable amount of man hours.

3)  Project failures are fatal.

Whether it’s a business that is counting on a project being completed by a certain date, or a manager scared their reputation will crumble after something went wrong under their watch, project failure rarely proves fatal. The important thing is to learn from mistakes that led to the delay or hold-up, and figure out how they can be avoided in the future. If you react to them in the right way, and treat them as an opportunity, failures within project management are nothing to fear at all.

I singled out these three issues because they are views that could potentially be held by three different parties: the certification issue is one for prospective project managers, while the paperwork issue is one for businesses considering the best way to approach a big project, or thinking about PM. The third and final point is to be kept in mind by all parties while a project is in play.


Do you agree with these three project management myths? Have you experienced others within the industry? Share or debunk your own: Follow / Like / Connect

Implementing and Sustaining a PMO Role

By Andy Wojewodka, Changepoint Sr. Business Process Consultant

So, Management has decided to move forward with a PMO role, and now you might be wondering “what’s next?” Keep in mind, you wouldn’t be hearing this decision unless there’s something wrong with the company’s current state. It’s usually tied to project delivery performance issues, the lack of timeliness and visibility of initiatives across the enterprise, or uncertainty regarding prioritization and selection of project investment focus. Addressing any of these areas (let alone all three) is a noble cause, therefore before tackling a PMO rollout it is essential to understand expectations, gauge how realistic they are, and create a roadmap ahead of time to ensure success and sustainability.

Understand Expectations

The role of a PMO is as varied as the number of diverse industries and business cultures. Some organizations have a PMO focus to communicate what is happening across the enterprise while other PMO organizations are established to facilitate a governance process for prioritization and conflict resolution. In addition, there are PMO departments held accountable to deliver the initiatives that have been approved by Management. Keep in mind that there are also many PMO departments with a combination of all three roles and responsibilities. It’s important as you get started to determine upfront what is expected from the PMO department and how well the stakeholders are aligned with the PMO’s roles and responsibilities across the enterprise. To get there you’ll want to ask yourself the following questions:

  • Is there a clearly defined charter for the PMO?
  • Do all stakeholders agree with the PMO’s roles and responsibilities?
  • Has an organizational framework been defined to support the PMO’s roles and responsibilities?
  • Will the stakeholders support the framework beyond simply approving a budget and giving lip service to the charter?

Determine Whether Expectations Are Realistic

Having an aligned set of expectations is one thing, but it is equally important for Management to equip the PMO organization with the assets and authority necessary to achieve their desired outcomes.  Even with these tools in place, stakeholders must recognize there is no silver bullet, and have the fortitude to withstand the impulse to revert back to old ways of doing things. In order to do so, the PMO must regularly ask themselves the following questions:

  • Is a governance framework in place to prioritize work and mitigate conflicts?
  • Is PMO empowered to achieve Management’s expectations?
  • Is the PMO organization sufficiently staffed to support the objectives?
  • Are there sufficient tools available to manage the objectives efficiently and effectively?

Develop a Roadmap for Success

Rolling out a PMO organization should be viewed no differently than managing any other large project. In other words, the foundation for success is applying and adhering to solid Project Management principles, which means requirements should be clearly defined with a solid project plan and adequate staffing needs to be in place to support end deliverables. With these principles in mind, you can create a solid PMO foundation by taking the following steps:

  • Plan the work and work the plan
  • Establish a steering committee with formal project updates and manage expectations appropriately
  • Establish a formal issue and risk mitigation process
  • Determine the impact of the change that the PMO will have on the organization
  • Develop appropriate Organizational Change Management (OCM) program
  • Track overall PMO performance against established baselines

Sustaining the PMO Practice

PMO sponsors and stakeholders need to maintain momentum well beyond the launch, because sustaining a healthy PMO continually requires the right people, processes, and tools to be in alignment. Don’t forget that a PPM or PSA tool can actually help keep these resources on track and focused on achieving goals of the PMO. Thinking of a PMO rollout like any other project allows you to categorize resources, prioritize, and set milestones which continually evaluate key performance indicators against established baselines. This evaluation process then pushes an organization to not only strive for continuous improvement but also realize the value a successful PMO practice can provide long after implementation. Although a PMO practice, like anything, will never reach perfection, keeping stakeholders engaged through active participation maintains buy-in and focus for the PMO role throughout its lifespan.


Have you experienced a PMO flop? How about a successful implementation? Share your rollout tips to avoid trials and tribulation on LinkedInFacebook or Twitter.


3 Ways to Ensure Your New Product’s Business Value

By Tom Yang, Changepoint Sales Engineer

Cha-Ching! To a Project Manager that’s the sound of your organization committing to a new product – knowing that now that the money has been spent it’s time for you to get things in place to support the investment. As with most large business purchases, but especially software, it’s essential you build a solid rollout plan to avoid or quickly address unforeseen obstacles. I know this from firsthand experience as I work side by side with our customers to implement our Changepoint and Daptiv PPM solutions, which in turn are then utilized to facilitate the rollout of many other products.  Time and again I’ve witnessed how a Project Manager’s ability to lay the foundation for a new product has been crucial in determining its level of attainable business value. To ensure you’re building a solid structure you’ll want to start with a product implementation plan focused on defining your goals, providing the transparency necessary to keep everyone on the same page and ensuring you’re prepared for any problems that are bound to arise along the way. Sounds simple enough, so here’s how you can get started:

Set SMART Goals

Aligning SMART goals with pre-stated business objectives is the best way to meet major milestones during a product rollout without confusion or major setbacks. Making goals SMART requires them to be: specific, measurable, attainable, realistic and timely. Therefore, when outlining the organization’s objectives the new product goals should go beyond the vague, “roll out budgeting to the PMO” to the more defined, “enable the PMO to track budgets on a monthly basis for all IT Projects and summarize quarterly.”

Ensuring business objectives are also clearly defined through these SMART goals eliminates any confusion over what your organization is trying to achieve or how they plan to get there. In addition, if an objective isn’t met on time it’s possible to determine exactly where the failure occurred and course correct. For example, perhaps a goal your team was targeting on a monthly basis was too difficult to achieve, but moving it to quarterly made it more realistic.

Tying these goals to timed milestones is key since it allows all teams and levels of management to hold each other accountable. If these milestones are missed (beyond the standard margins of 5%-10%) you’ll know it’s time for either the goals or the timeline to be re-evaluated to account for any delays. One tip to minimize confusion, but keep goals measurable, is to start with time estimates (I.e., It will take two weeks for each module) as opposed to setting actual dates (Module 1 will run from 1/1 – 1/15.). This way if you have to make a shift it’s much simpler for teams to adjust those time frames and you stand less of a chance of mixing up dates.

Ensure Transparency

While implementing SMART goals goes a long way in providing transparency around the product implementation mission, you can’t stop there.  It’s crucial that you also work to provide a similar level of clarity to your teams around roles. You can do this in part by clearly identifying the main vendor point of contact for the product purchase, their specific responsibilities and a backup or manager. Ensuring transparency at this stage is key, because the primary contact during the product sales cycle will likely not be the same person assisting your business with all of its deployment needs. Since it is rare to work with the same people on both pre-sales and post-sales efforts you should request a knowledge transfer call that includes all those individuals and your team to make sure everyone is aware of your organization’s needs.

It’s also important to be clear on what responsibilities fall to the product vendor, as well as the scenarios during which it’s likely that they will need to bring in additional resources or send issues that arise to another team, to limit surprises and setbacks. If you fail to define these areas to your teams before rolling out a product it can leave them frustrated as each issue is investigated and resolved slowing down the deployment progress. Here’s an example I’ve experienced:

A vendor I worked with offered and even touted their ability to create “customized grips” for certain products. However, when asked to add them during production it was revealed that the process was actually carried out by a foreign subsidiary, which added three weeks to turnaround time. While in theory, a typical product deployment shouldn’t require extensive additional resources, in those rare cases the vendor should be able to explain them beforehand and you should remember to ask. This helps to limit surprises, and at times keeps the vendor honest. In this example, if my team had been clear on what the immediate vendor could provide as well as the process for getting other needs met we would’ve been able to account for the project delay.

Process Your Problems

Since every problem is unique, the best and often only way to prepare for them is to establish a process that lays out exactly how they should be addressed and who will handle them when they arise. Being prepared with a process for managing problems is critical to keeping a product rollout on track. For example, something as simple as the best method of communication needs to be identified and stated early on. This basic knowledge allows teams to know whether they should email or call to effectively escalate an issue. This process should also dictate when an issue in the product rollout has reached the threshold of being a full blown problem or is actually just a delay that can be accounted for by shifting milestones. Another tip for ensuring you’re prepared for anything is to ask the vendor to walk you through some of the common obstacles they’ve seen in similar deployments, which should give you some insight into what to look out for and the kinds of solutions your product vendor is likely to provide.

Spending the time upfront building out these three elements will go a long way in making your implementation journey less bumpy, which increases the likelihood of a product’s success and ultimately the value it provides to your business.

Have you saved your own company from a product rollout disaster? Share your tips to limit sweat and tears on LinkedIn, Facebook or Twitter.


Project Honeymoon

Sometimes projects don’t quite go as you expect them to.

My wife and I recently returned from our honeymoon in Namibia.  The country is truly an amazing place and I cannot recommend visiting enough.  Otherworldly scenery and fantastic wildlife viewing went hand and hand, day after day.  It was the trip of a lifetime but at times it was a different trip than we planned.

We thought we had our itinerary all planned out when we arrived in Windhoek, the capital city.  An old/nonexistent booking system caused some confusion at the lodge we planned on spending our first night.  Lucky for the two of us, we had rented a 4×4 with camping gear.  What’s the use of a 4×4 if you can’t get it dirty?  We changed our plans, shifting our entire itinerary and headed in the opposite direction and into the Waterberg Plateau, along hundreds of kilometers of sand and gravel roads.

In the initial stage of a project just one small hiccup can alter the whole direction of a project.  Sometimes that’s a bad thing, sometimes it’s not.

Camping earlier and for more nights than we planned changed the entire trip for us.  We decided we didn’t need a lodge at any point of the trip and kept exploring the national parks from a more humble viewpoint.  In places where predators lurked, we stayed in fenced in camp grounds to keep us safe but in smaller areas without lions we had a much more open experience.  Chasing monkeys away and waking up to warthogs in your camp are memories we wouldn’t have had in a lodge, no matter how luxurious a lodge that might have been.

Sometimes when travelling, being flexible makes the whole experience better; on occasion, the same is true for a project.  One small early change can point your project in a new direction.  Sometimes a new direction is indeed for the better.

Happy Valentine’s Day.