PPM: Everyone Gets To Play (Part 2)

In continuation to my previous blog post, this one will explain how the PPM needs of organizations drive the overall implementation process. At the enterprise level, we all recognize that different types of businesses execute different types of projects. The project portfolio for an investment bank is going to look a lot different from the portfolio at a company that designs and builds computer products, or a hospital, or a university. Even when we look at similar enterprises, we find differences in strategy, culture, and approach. Since many of these differences are the fuel for competitive advantage and operational excellence they require processes and practices which support those unique attributes.

Likewise, we need to recognize significant differences between functional areas  within the same enterprise due to the nature of the work being executed and the varying ways in which that work is done. The PPM needs for the product engineering groups are not exactly the same as those in HR.

Let’s take scope management as an example. For a company that is building something under a contract for another company, control over the scope of the project may be critical to assuring company profitability and in the most extreme cases the financial viability of the supplier organization. In this case, one would expect a much more structured, formalized set of processes for reviewing and approving scope changes and making changes to supporting contracts, payment schedules, etc. By contrast, when a department in one organization needs to communicate and manage expectations around delivery dates and costs for a sponsoring department within the same company – especially when the sponsoring department has requested the change — they may adopt a less formalized, lighter weight scope change process. In both situations changes the “what” of scope management is the same – scope changes need to be recognized, communicated and approved – but the “how” may be radically different.

We must also take into account that the approaches, tools and techniques used, even within a discipline may change over time. For many years, the construction industry used the Design/Bid/Build phases in their projects where each successive phase was substantially completed prior to the commencement of the next and each phase was executed by different organizations. Unfortunately, as a consequence of this approach many projects were plagued by a fourth phase, “litigation”, with finger-pointing and lawsuits between the parties to establish whether something was a defect in design or a defect in construction. Now many construction projects are using an approach called “Design/Build” where the work is performed and managed as a single, integrated effort. Similar changes have occurred in information technology, where new development tools and approaches have facilitated iterative and agile development of applications and business systems outside of the lockstep waterfall techniques of the past. Each of these has required new techniques for how the projects using them are planned and managed without losing the visibility needed for oversight and control of the outcome.

The most successful PMO’s and ePMO’s are those that understand the underlying goals and objectives of PPM while implementing supporting processes that are adapted  to the unique, changing needs of the enterprise, and the functional groups and disciplines within that enterprise. While this requires open-mindedness and creativity the adoption of PPM across multiple disciplines in thousands of companies is proof positive of the feasibility and be benefit to be derived from the effort. In short, despite the declaration of that gentleman at my first PMI meeting – PPM is relevant to Information Technology. And  to Finance, Marketing,  Professional Services,  New Product Development, Manufacturing, Supply Chain Management, Education and any other discipline or organization that invests in and executes projects. It also still applies to Construction and Engineering…

As a post-script I would add that since that first meeting I have belonged to PMI for many years and attended numerous meetings in a variety of other locations and chapters which were well attended by individuals from a wide variety of organizations and disciplines.

10 Ways to Absolutely Ruin your Projects

Instead of providing a list on how to successfully run a project management office, I chose a different route and set out to assemble a list of valuable information that guarantees project failure under any given circumstance. If you are a project manager or run a PMO, the recommendations you will read below are full of promise and will definitely get you into trouble.  With that in mind, here are…

10 Ways to Absolutely Ruin your Projects

  1. Start a project without a defined goal or objective:  Like a ship without a destination or a race without a finish line, starting a project without a goal is an exercise in running in circles.  No matter how much time, effort or money you through behind it, you’ll never accomplish what you set out to do because it was never clearly defined.  Then again, it’s also a great way to stay out of trouble because you’ll never know when your project is ‘moving sideways’.
  2. Run a project that is not aligned with the company’s objectives:  I know ‘mobile tech’ is really cool.  So is ‘social media’.  So let’s kick off a project to do that.  Wait a minute.  Did we ever check with our customers – both internal and external – if this is what they are asking for?   Do we know if this project help move the company’s goals forward?  I don’t know, but let’s call it “Rogue Project” because it sounds so cool.
  3. Manage a project that does not have a sponsor’s support:  Like a football quarterback without his offensive line, running a project without a sponsor to provide direction, remove obstacles, and ensure support to move the project forward is a great idea.  Please let us know how that works out for you, OK?
  4. Make a project more complex just for complexity’s sake:  If two levels down into the work breakdown structure is good, six levels is great.  It’ll show people how much more smart and experienced you are than them.  If you can do this effectively, it leads to…
  5. Micromanage your team, especially the senior level people:  Which studies show is a great way to lose supporters. Really fast.
  6. Don’t consider the benefits or ROI before you kick off the project:  Project benefits are so hard to define.  And who knows if we’re ever going to achieve them anyway.  So let’s not worry about it.  Just give me that bag of money so I can start my project already.  It’s not about value after all – it’s about working with cool technology.
  7. Recreate the wheel when starting a project:  I know my organization has done something like this before, but I’m really, really smart and don’t need the help.  I’m happy to start all the deliverables from scratch.  Or maybe this time I’ll just make up a new methodology.  Why recycle and reuse when I can just recreate?
  8. Allow your project’s scope to change on a whim:  if we don’t have a good change control process it makes the project easier.  If we learn new things, let’s quickly move in that direction.  We can call it ‘iterative execution’.  Just like a new puppy deciding if he wants to chase a ball, bark at the other dogs or have a snack.
  9. Don’t check in with the stakeholders or customer through the lifecycle of the project:  we already understand what they want, so bringing in them back in as we move through the project will only give them a chance to get more engaged and supportive.  Nah…let’s just surprise them at the end.
  10. Spend, spend, spend:  Don’t worry about budgets – they’re just rough estimates, anyway.  If we need to get more developers and fly the team out to Las Vegas for a workshop, so be it.  By the time the financial team finds out it will be too late anyway.

Hopefully the list above is taken as a cautionary tale – maybe even a checklist of what not to do.  How do you stack up against it?

It’s Time to Learn and Interact at Daptiv’s PMO Success Webinar Success Series

Early this week we announced the launch of our upcoming PMO Success Webinars for 2012, aimed at offering real-world guidance on how to build and run a successful Project Management Office.  This free educational series will provide insights and perspectives from PMO Directors and Consultants at organizations running successful PMOs as well as Daptiv’s professional services team.

According to research performed by industry analysts such as Project Management Institute (PMI), the Gartner Group, and Forrester Research, 25% of all PMOs closed within one year and 50% closed within two years. Clearly, PMOs face significant challenges within their organizations. On the other hand, the need to successfully complete projects has never been greater.  Most companies recognize that projects are a major vehicle by which companies grow, improve and meet their business objectives.  The need to plan, monitor, and execute projects has never been greater. Companies decide to setup PMOs to do just that but they often fail to get the desired results from them.  Daptiv’s PMO Success Webinar Series will shed light on how companies can prevent the fall of PMOs and instead turn them into a strategic asset.

We kick off our first webinar titled, “Are You Ready for a PMO” on Tuesday, September 25. It will focus on how organizations can assess the need for a PMO and how they should go about setting one up. Come join the discussion with 250 industry professionals who have already signed up for the series. Panelists will include Mark Perry of BOT International and Dave Blumhorst of Daptiv Solutions, LLC.

To find out about more the Daptiv PMO Success Webinar Success Series, click here.

Building and Maintaining a Lean and Effective IT Governance Board

Lean.org characterizes Lean as:

“Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.”

Lean.org defines Lean as:

“To accomplish this, lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flowof products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers.”

Building a Lean and effective IT governance should not be transformational but transitional.  It is a major shift for an organization whose only governance is the command and control of the organizational chart.  Simply implementing a PPM tool is not the answer. In the book “The Information Paradox”, by John Thorp  Copyright 2003, McGraw / Hill, states that there are three necessary conditions for an effective governance:

  • Activist Accountability
  • Relevant Measurement
  • Proactive Management

Well technology can’t deliver these three conditions, they’re organizational. However a PPM can contribute to sustaining the knowledge, specifically with Relevant Measures.  It can be the single source-of-truth. Implemented correctly the PPM system IS the repository of the decisions the organization has made in the past.  This means that any governance placed in IT investments must also have the same scrutiny place on the ‘relevant measures.’  Relevant Measures must evolve with the rhythm of business.

As I said earlier, a governance needs to be transitional, it is a continuous improvement process and needs to be implemented at the rate the organization can absorb the change.  Activist Accountability!  Commitment needs to up and down the organization with strong leadership.

To start with the governance needs stewardship. This classically comes from the PMO, but as it has been will documented this isn’t the process/methodology police.  The PMO needs to be open and clearly communicate the “vision of the end” at the beginning.  A lean effective governance is more than how you run a project or any investment for that matter. That’s why it is important to recognize that governance is a combination of two major processes; the first being the project life cycle; the second is the portfolio process.  Your transitional strategy needs to take both of these into mind. And these processes should be instantiated in the PPM tool. Another key to governance is the roles in the governance and the exchange of information and dialog between them.  Oh and this is NOT an organization chart! But is a make-up represented cross-functionally. The roles are:

  • PMO – Is the steward of the governance.  The make of this is more that just project managers.  It needs vision and leadership capable of being the “trusted advisors” for the complete governance. The PMO is the champion for change. Not only does the PMO
    require the PMs but needs the vision and the moxie to champion the “roadmap” for the governance’s evolution.
  • Decision Board – Represents the needs and priorities of the governance.  It’s made of the business leaders accountable for the introduction of change from the investments in the portfolio. The Decision Board is accountable for the decisions of the portfolio make-up and the Relevant Measures.
  • Steering Committee – Represents the needs of the project, program or investment.  This is different from the decision board its scope IS narrow, but necessary.  I’m not going to elaborate on the Steering Committee; its role is well documented in project methodologies like the Project Management Institute’s Project Manager Book of Knowledge (PMBOK).
  • Project Manager or Program Manager or Initiative Manager or Investment Manager – They all fulfill the same role – Investment Steward, one of the most important roles in the governance.  The investment steward is accountabledelivering on investment outcomes.  Againthis is a well-documented role.
  • Project Members – Yes they are considered as part of the governance and are sometimes left out. Their role in the governance is to deliver capability as prescribed by the investment steward and communicate progress on that delivery.

Those are the primary roles, however in more mature organizations there exists two more roles, they are:

  • Portfolio Manager- In highly evolved governances the Portfolio Manager is accountable for the performance targets or outcomes of the portfolio. The Portfolio Manager is part of the decision board and advises the decision board on investment scenarios and portfolio adjustments.
  • The Architecture Review Board – In conjunction with the Steering Committee this board is counseled for any impact to the enterprise architecture. Now wait, this not the standards police! The architecture board is made up of enterprise architects and is accountable to ensure that an investment does compromise the direction of the enterprise architecture.  Enterprise Architecture is a topic in of by itself and there is much written but in no means is the scope of the blog post.

This post is about Building and Maintaining a Lean and Effective IT Governance Board, I’ve touched on mostly the building part, but maintaining?  I’m not going to fool you that is the hard part. But the key to remember, this is a continuous improvement process.  People are likely to move on, especially in the leadership, that’s why keeping the governance going is not one person responsibility.  How does that saying go…? “It takes a village…” and change is good!

By keeping up with the rhythm of the business you are always ensure the portfolio is working on the Right things, the Right way, things are getting done, and the governance is realization the full benefit and potential.