The Business Driven PMO

I talk to clients and prospects on a weekly basis about “What-If” analysis; most of the time the conversation revolves around capacity, specifically having enough resources to execute work. Too often project managers keep their focus on the capacity problem.  However, the problem they truly need to address is a portfolio problem, a demand management problem.  This is true for every organization except those whose revenue is driven directly by their ability to meet the demand, such as professional services organizations.

When clients tell me they’re overworked, there’s a tendency is to focus on capacity issues first. The fundamental question then becomes, are you working on the right things?  Although capacity is one of the common constraints in portfolio management, initiating planning exclusively to focus on managing capacity is fraught with errors.  Organizations focused exclusively on workload have a tendency to manage resources at a micro level and that just isn’t sustainable.  I once had a client where, when he moved his focus from matching capacity to demand and began focusing on the right things, the dialogue changed and he became more connected to the business. Dialogue between the organizations ensued that actually increased the quality of business outcomes.

Ending up with an optimal portfolio is a two-step process. First is to align the portfolio of projects to match the performance objectives (business outcomes) of the portfolio. Second is then to match capacity to that portfolio scenario.  This is an iterative process until you end up with the optimal portfolio.  Don’t be afraid to review these decisions throughout the year -  as business rhythm changes, so might the portfolio.

Aligning the Portfolio

The best practice approach to aligning the portfolio is to first identify the correct mix of project investments that fit the performance objectives of the portfolio. Different outcomes require different analysis; one or more of these approaches may be required to complete the what-if analysis:

• Strategic Intent – focused on completeness of strategic vision or fit. Classically visualized with investment maps (bubble charts). As an example, the x and y axis represents Timing and Risk (although a priority score containing risk is also acceptable). The bubbles represent the project or investment. And the size of the bubble is either cost or an economic return metric such as ROI.  This is a simple, efficient approach and the key is interpreting the “shape” of the investment map (we will need to address that later).  For more portfolio mature organizations, an efficient frontier approach may be appropriate.
• Diversified / Balanced Intent – To provide insight on the right mix of investments. We never want to put all of our eggs in one basket.  This is particularly true for organizations that need to maintain a particular quality level of existing assets. IT organizations have  infrastructure and legacy applications where they need to maintain an acceptable service level agreement. If they don’t renew those assets, and only work on high priority projects, then the expense that the business will eventually need to incur to “fix” those neglected assets could be devastating to the budget. To visualize Balanced Intent, classifying and stratifying investments into those import investment categories and using pie or bar charts to understand the mix of investment is considered a best practice.
• Operational Intent – To provide insight on demand versus capacity.  Although an advanced method, Operation Intent classically takes the selected scenario from any or a combination of the above techniques and applies capacity to it -- Capacity as aggregated to “resource type.”  Ideally that would involve a prioritization metric that will allow scenario analysis to individually adjust the scenario by adding and subtracting projects from the scenario.
• Risk Intent - classically an advanced portfolio technique used for asset analysis and product portfolios. Risk intent analysis would include:
• Market attractiveness versus Business strength and competiveness
•  Tornado charts that evaluate the risk range of multiple topics

Setting up What-If analysis correctly and capturing those scenarios (and the decisions on the scenarios) makes the process go smoother.  Revisiting those decisions and reprioritizing becomes simpler.  Adding and subtracting investment into the “buckets” created for Balanced Intent allows organizations to focus on business outcomes with multiple lenses and not a single view, creating a true apples-to-apples comparison.

Most CIOs struggle with a common problem: the insatiable demand for IT work from other departments. Most strategies for dealing with this involve work request intake processes and prioritization schemes. Some may take the extra step of allocating their resources, usually against projects. But if you simply look at the problem statement, the path to a solution becomes more obvious. To balance the load we must match the incoming demand for work against the supply of resources to perform it.

In many IT departments this work comes into the organization in an ungoverned fashion. Minimally, support work may come in through a help desk system, but sometimes not. When not flowing through a defined process, projects may come in via email, hallway conversations, or direct requests to technical staff. This subjects all staff to the dreaded “death by a thousand paper cuts” as work comes from all directions to just about anyone in IT.

There are several keys to successfully balancing IT’s often overwhelming workload:

1. Consider all of IT’s work and staff, not just projects and programmers. As everyone in IT may get involved in the various types of work IT does, narrowing in on just one aspect will not solve the problem.

2. Govern the workload by scale. Tickets are governed by help desk queues, enhancements by targeted percentage policies, and projects by a formal intake funnel. Each of these groupings is governed in a different fashion, each ideally comes through its own intake process, and therefore each needs to have resource allocations planned differently.

3. Plan capacity early. Like any other department that produces tangible product – in our case various technologies – a little planning is in order. Capacity planning is the science and art of aligning all incoming requests with the proper work teams and deciding which ones hit the floor when to make the most efficient use of available capacity. Just like in manufacturing, capacity planning must be done long before efforts like projects are launched. Done properly, this reduces the scramble for resources and minimizes conflicting priorities. It also allows more work to complete without interruption, reducing inefficiencies caused by churn.

4. Track all time. To truly understand the workload in IT, everyone from the CIO on down must log their time. It is simply not possible to segregate the work by one specific IT area or one type of work – no matter how the department is organized. At a minimum, they must log time to the different scales and types of work and to individual projects. Without this critical feedback, even the best planning process is just guesswork. 

Above all, IT’s job is to provide information technology that supports and enables the achievement of business strategies and goals. Ensuring that all work is properly governed and planned helps IT stay in alignment and deliver to those goals efficiently and effectively.

We all feel the pressure of “Do more with less.” Run lean. Increase quality. Move faster. These are not just management-speak, they are reality. The macroeconomic climate of the past few years has mandated we find new ways to increase efficiency or be left behind.

Successful teams are finding new ways to use their tools to meet these pressures.  By defining a single source of truth that is available anywhere, anytime you can begin collaborating in real-time for leaner execution.  How does this work? Let’s take it piece by piece.

Single source of truth. The first step is to ensure stakeholders understand which systems are the systems of record for a given type of information.  Your financial data goes in your financial system.  Your project planning and execution belongs in your PPM system.  HR information in its system.  Integrate them for the big picture view but define a single system for each function.  Constantly reinforce with all stakeholders the need to keep the systems current in real-time.  Putting off your updates to the system will keep your organization from finding that next 10% in your business.  Wondering if the data is reliable will restrict your ability to be nimble. 

Available anywhere anytime. Make sure your systems are available wherever and whenever your stakeholders are working.  Productivity is now pushing us round the clock and round the globe and our systems need to support that. If yours don’t, you need to look at new systems. SaaS and cloud technologies are making it clear this is the new norm.  Removing any friction in accessing your systems will ensure the single source of truth remains reliable and accurate. 

Collaboration in real-time. Change how you work together (with another individual, an executive steering committee, etc).  Always open up your management tools and use them in meetings.  As we all have increasingly distributed teams this is key to keeping everyone engaged and aligned.  Guide the discussions based on the data in your system of truth.  This keeps the discussion focused, generates buy-in (“we all saw it in the meeting”), removes ambiguity and creates accountability.  Capture decisions and changes in your systems as the meeting is happening.  If your systems make it too cumbersome to edit information quickly consider new tools or push vendors for better user interfaces.

By defining a single source of truth, ensuring your systems are available anywhere anytime, and collaborating in real-time, you will help your teams do more with less.

Back in my CIO days I received a call from the VP of Sales who was travelling in Helsinki at the time. That I had a 24x7 global support team was not relevant – he was a VP and felt entitled to call me at 2 AM in California with his urgent problem – to wit: “Dave – email is down and I’m working on a critical RFP! DO SOMETHING”. Of course my next call went to my support team, which promptly informed me that no, the Exchange server was up and running. After a few moments of groggy contemplation, I shot back:

“Bob in Helsinki doesn’t care if the problem is the Exchange server, the router, his Internet connection, the Outlook client, or any other piece of the puzzle – all he wants is his email – and it’s your job to figure out why he’s not getting it”.

This leads to two major lessons. First, don’t roust a CIO at 2AM – we can be a bit testy. Second, users care about the business services we deliver, not the technology behind them.

This story is a classic example of a business service provided by IT. For the most part, we should build IT around business capabilities required by the enterprise. This means they should be labeled with business terms. While email may also be a technology, it is today a universally understood business term as well – as demonstrated by my friend Bob. Other services commonly provided by IT would include Inventory Management, Sales Force Support, Customer Account Management, Lead Distribution, Supply Chain Management, etc. etc.

This story also illustrates one of the core difficulties of IT. While the enterprise needs business capabilities, what we deliver is the underlying technology to enable those capabilities. We need to somehow translate those business needs into technology delivery components.

To achieve this, it helps to start from the top down in the world of strategic enterprise architecture. Done right, EA consists of a stack that starts at the top with business needs, drills down into the applications needed to support those needs, then further down into the infrastructure components (servers, networks, etc) needed to support those apps. The idea is to design from the top down and build from the bottom up.

To get at that top layer of business needs it helps to divide them into like groups. Organizational groupings are a great start – starting with Enterprise needs (think email, telephony, productivity, etc) then into individual departmental needs, like financial automation, sales support, and manufacturing processes. Inside each of these groups is a set of capabilities. Let’s take financial automation as an example. We could break that down into the automation of the major finance processes – quote to cash, procure to pay, and record to report. We can then look at the applications needed to automate those processes – the first technology layer. For quote to cash, this would typically include the quoting module of an SFA system like Salesforce, the Order Management, Invoicing, Accounts Receivable and GL modules of an ERP system (like SAP) and perhaps a Business Intelligence tool like Cognos.

Finally, to support those systems we need the Infrastructure components – servers for SAP and BI, network and internet components for those and Salesforce, and client components for the desktops/laptops.

So, a completed EA stack allows IT to understand all the components needed to support the delivery of a business service. And this information provides the basis for building our service portfolios. While the business needs are services, those like groupings of business capabilities are the service portfolios.

When building service portfolios, I recommend sticking to a couple of basic rules:

1. Make sure your portfolios group like business services – like all the financial services or selling services.
2. Make sure your underlying services are stated in business terms – not technology terms.
3. Make sure these services provide business value and can be measured (eg: % of email delivered, orders processes per month, inventory turns)
4. Review the completed portfolio and services list to make sure it is comprehensive and makes logical business sense

ITIL V3 talks at length about Services and Service Portfolios, and I think a true understanding of how to build those services and portfolios comes from this enterprise architecture view. Without it, you could end up with service portfolios that look like “Application Services” and “Communication Services”. These still talk about technology and won’t make sense to the average business user.

Just imagine Bob’s response if I tell him we’re having a “Communication Services” issue. He’d say something like “you’re darn right we’re not communicating! Now how do I get my email?!?” 

Many project portfolios now includes a mix of project types and methodologies, such as traditional waterfall projects, agile-based projects, six-sigma projects and ‘stage-gate’ projects for new product development. I’m continuing my agile PPM myth busting series today addressing the third most common fallacy: Agile and Traditional Practices Aren’t Compatible.

Project management leaders have, for the most part, embraced agile practices and have attempted to redefine their roles to focus less on planning and controlling agile projects, and more on providing an environment to allow agile projects to succeed.

However, even with this willingness to adopt agile, integrating agile projects into a PPM framework has proved challenging for many organizations. Project managers are being faced with different (and often conflicting) methodologies, metrics, and controls. In addition, some teams are adopting ‘hybrid’ processes that include elements of waterfall and agile methodologies and are confused about how to rationalize seemingly incompatible methods. To solve these challenges, PMOs require an updated framework that incorporates agile practices, provides clarity to project teams on how to communicate project health, and provides predictability and accountability to executive stakeholders.

Integrating an agile project methodology into a PPM framework is no different than integrating a more traditional project methodology, with four exceptions:

(1) Agile teams work best when executives and project managers don’t stifle the agile process. Imposing unnecessary stakeholder reviews, checkpoints and data capture requirements on an agile project will reduce the effectiveness of the team. Of course, if major decisions need to be made with executive input or the agile project has dependencies on other projects, stakeholder meetings will be necessary, but these should be the exception, not the rule.

(2) Agile projects measure progress ‘story points’ complete or business value delivered. This is a fundamentally different way of tracking progress than using a task plan and measuring task hour completion. In addition, a project manager assigns tasks to owners in a traditional project, whereas agile teams are often self-organizing, so tasks may be reassigned at any time by the team to ensure project delivery is on track. This difference requires that metrics for ‘project health’ and ‘percent complete’ are tracked differently from projects based on task hours.

(3) Given the task assignments within an agile team are dynamic, it’s unwise to assign a resource part-time to an agile team as this breaks the self-organizing model. Instead it’s better to treat agile teams as a unit and assign resources to them full-time (with the exception of resources such as technical architects and DBAs, which are typically spread over multiple projects).

(4) Finally, regular reviews of agile projects are more focused on ‘working software’ than reaching pre-determined milestones or delivering project documentation. Reviews should be tailored to the type of project to ensure they are valuable to the team.

It’s true that some agile practices have fundamental differences with some traditional project management practices, for example the planning and executing process groups in the Project Management Institute’s (PMI) Project Management Book of Knowledge (PMBOK). However, it’s untrue the two types of practices can’t be combined to create a powerful project management framework.

For instance, agile practices are usually silent on project intake or project initiation processes, and traditional practices for project cost, communications and risk management are often more mature than the corresponding practices in agile. An experienced project manager can add practices from the PMBOK or similar methodologies to support agile projects without disrupting the culture and work practices of an agile team.

Have you brought together agile and traditional practices successfully? Let me know!