Some of the best ideas come from employees and are not top-down driven from strategic priorities.Walk into a new transformation role three times in 10 years, and you get to see some patterns. In all three instances that I have done this, I start my review with leaders with one simple question. Think about the time you met your team or your colleagues for the first time in a group setting. Once you go through introductions, you’re likely going to ask individuals and the team what they are working on. What are they doing today? Why are certain projects a business priority? How is everyone going about solving today’s challenges, and what is being considered as the next potential business initiatives?
I do this with a very simple question that tends to unravel the fabric of how the business is functioning, whether there is alignment on priorities, where there may be execution issues, and whether the business has a healthy culture for taking risks and making investments. That question is . . .
The simplest of questions easily exposes the messiness of running IT, product, marketing, and data science organizations. The larger the organization, the more likely this simple question will lead to others that expose larger business challenges, cultural dysfunctions, execution roadblocks, talent gaps, funding constraints, process immaturities, and other considerations that impede transformation. This is not necessarily a knock on previous or current leadership, especially if you’re coming in as a new leader with a different perspective or new priorities.
To answer this relatively simple question, you’re probably going to get a plethora of answers. First, it’s likely that some won’t be able to answer this question immediately and will ask for time to get organized. Others will show you spreadsheets with incomplete and inconsistent information. You’ll be given tours of different tools, maybe even an agile project management tool that will give you some sense of either development or operational projects. Some will show up with recent reports or presentations they made to management on the status of active projects. You’ll find duplicate projects with different names, large multiyear programs with many subprojects, smaller to-do’s that shouldn’t be considered projects, projects that are already done, and others that have no hope of ever starting.
My absolute favorite is when someone shows up with an export and aggregation from the time reporting system. They will tell me, “This is the best system to record everything going on in the business or department because everyone is required to track their time in it.” What do these reports typically show me? A list of projects, who’s worked on them, and how many hours they worked. Perhaps it’s granular enough to break projects into different tasks or task types, but I can bet there are many data quality issues at this level even without asking the team. In most cases, time reporting systems give me little information on what the project is, why it was prioritized, what business benefits are expected, whether success criteria are defined, how close to the target timeline is the current forecast, and whether expenses are in line with the budget. The data in these systems helps the accountant allocate costs and respond to auditor questions but provides little help when trying to understand the health of the portfolio or to identify opportunities for process improvement.
Imagine following this up with some more questions. Maybe I’ll ask the CEO the same question: “What do you think everyone is working on?” Here I am more likely to get a slide or two from the last presentation to the Board of Directors outlining the company’s strategy, a high-level list of projects, the business owner, and the current status. Now this is useful and a good tool for a top-down audit of the organization’s priorities and working dynamics, but is the CEO’s response a sufficiently complete answer?
The answer is no. It’s a Board presentation intended to show a high-level view of a handful of strategic initiatives. What if I follow up with another question: “Is this everything that’s being worked on at the company that’s vital for hitting revenue targets, growing the number of customers in targeted segments, addressing business risks, or developing new organizational capabilities?” Good luck getting a detailed answer from the CEO to that question, and in many cases, you just lost the CEO’s attention. If you didn’t, chances are she’s just assigned you to deliver that report . . . in a week. Good luck putting together a full enterprise view of everything in progress when your colleagues and predecessors have never aligned or collaborated to assemble this view in the past.
As hard as it is to get a picture of the current state of organization and individual priorities, how about asking this next few questions? “What is everyone working on next? . . . What are the priorities for the next ninety days and for the full year? . . . What do you think will spill over to next year?”
I’ll probably get some answers from the CEO on this question. She’ll whip out the three-year plan and the five-year strategy. It might be a nice deck showing market conditions, company opportunities and threats, strategic priorities, and the company’s attempt at a forward-looking financial pro forma. Microsoft should add an Excel formula that helps the strategist draw the angle of the hockey stick of growth.
We can debate the usefulness of multiyear strategies when market conditions and technology capabilities have changed so drastically over the last few years and are unlikely to slow down. In 2010, did GM have a driverless car strategy? Did Marriott view condominium owners in large cities as a competitive threat? Did Honeywell look at Apple and Google as next-generation competitors?
Even when it is valuable, I find the ability to translate a multiyear strategy into executable plans a gap for many organizations. These plans serve a purpose aligning leaders and employees to a strategic vision. There may be some governance enabling the alignment of investments and projects to the strategy. There may also be a negative by-product, with some leaders pushing initiatives because of their alignment to strategy even when it doesn’t have any tangible business benefits. But most important, many organizations struggle to define, communicate, and manage a defined process moving from strategy, to a portfolio of planning projects, to execution.
Capturing, vetting, and tracking an organization’s initiatives may sound boring or be perceived as administrative overhead. Hire a project management office (PMO) to develop and oversee? Borrow a portfolio management process from one of the big consulting houses? Leave the definition of strategic projects to the CEO or key executives to manage at a high level? I would estimate that many organizations have tried one or more of these approaches and probably switched models multiple times over any ten-year period. Why? In simple terms, because top-down practices are too slow to match market conditions, too narrow in scope to ensure competitiveness, and too isolated from operating realities.
Strategies are most often top-down statements on the direction leadership is promoting to grow the business. While this is important and useful, it is not complete or sufficient in today’s fast moving and competitive world. Millennials have a vastly different perspective on what’s important now and in the future versus the boomer generation filling most of Board and leadership seats. Sales, on the front line of engaging new and existing customers, struggle to capture and keep up with the wants and needs of buyers. Customer service teams know the most frustrating complaints from end users. Aligning priorities to a top-down-driven strategy is no longer sufficient, and in today’s digital world, it’s more important to ask and solicit a larger scope of ideas from a greater pool of people.
Ask employees and leaders at all levels what their best ideas are for the firm to grow, win business, or become more efficient, and you’ll get a wide range of answers. But you’ll get answers, some of which will align to strategy, some of which will be good ideas but not worth pursuing, some that will be totally infeasible, and others that may just be the next big idea for your enterprise. But you won’t know about this great idea unless you ask. When you do ask, be prepared for a number of responses.
Some of the responses will and should come from the sales team. Chances are that they’ve been given a portfolio of products to sell, a territory, a ranked list of existing customers and new prospects, sales tools to be successful, and a sales management process that has the accumulated organizational best practices on winning business. Now ask a group of experienced salespeople what they want to sell, and you should get a noisy response. Taken to an extreme, you might get a list of the optimal list of things to be sold to a small group of clients on the salesperson’s list for him to exceed quota.
Ask the same question of someone in an operational role, and you’ll get a list of frustrating, inefficient, manual, error-prone steps her teams must perform repeatedly. They’ll want to automate steps, plug in new suppliers, capture better data, speed things up, enable greater configuration capability, and make other improvements that will make their key processes more efficient, reliable, and robust.
Ask the Security or Compliance Officer, and you’ll get yet another very important list. If you’re lucky, the marketing team has a list and partners well with technology leaders on vendor selection and implementation. Finance probably has a list, but don’t even bother to raise their voices because they are last in line for funding or resources.
Here are the questions: Can these different organizations fulfill their needs in silos, or do they need collaboration from other departments to be successful? Is the change impact of any initiative understood sufficiently? When funding is required, how are these decisions made to align with strategy and ensure that there is some balance where funding is applied among growth, efficiency, research, and compliance driven initiatives? These are key questions that having portfolio management practices aims to address.
Every organization I’ve been a part of has the challenge of prioritizing resources toward the best ideas. The complication is that many projects and initiatives that are active or being planned are difficult to capture in a single place, let alone manage them. Compounding the issue is every business’s need to prioritize investments in different categories. Most executives prefer prioritizing revenue-generating initiatives, but they should be balanced with others that provide cost savings, efficiency, compliance, security, and other operational benefits. Finally, all organizations and especially those that prioritize digital transformation should invest in R&D and innovation activities.
Why haven’t more organizations looked to centralize the data, practices, and governance regarding their projects, initiatives, and investments? The need to have some idea of the organization’s priorities and where funds and resources are being invested is so fundamental, yet so few organizations are successful at achieving a basic project portfolio. There are several reasons, and most organizations suffer from several issues.
There may be a lack of support from top executives who have interest in some of the more strategic initiatives and the ones consuming the most resources. They often have little interest reviewing the long tail of other projects that still require management and resources. These executives may not appreciate the importance and effort required to develop a comprehensive project portfolio.
To some executives, portfolio management is often viewed as an IT activity and delegated to the CIO to manage. The portfolio then centers on technology projects or ones that require technology investment and often falls short of representing other sales or other departmental initiatives.
Some business leaders are not interested sharing information on their initiatives especially if they have questionable ROI or do not require investment of resources out of their control. Many prefer managing these projects quietly and publishing their results of only the completed ones that yield successful results.
When CFOs drive portfolio management, they often align it with ERP and try to centralize the portfolio, list of projects, resources, and applied effort in these tools. ERPs are expensive platforms to develop on and are not the day-to-day tools used by teams to complete their work or manage projects. Centralizing project portfolios in an ERP is problematic if it requires the staff to duplicate data and creates additional administrative steps to report in a separate system.
CIOs have also made mistakes selecting and implementing project portfolio management tools. Pushing these tools in large enterprises often yields resistance when they are misaligned with team project management methodologies and tools. If the workflow is centralized, implementing in the tool is more efficient, but complications arise in defining KPIs, metadata, and workflow appropriate to all business types. Larger enterprises have the added complication of getting multiple businesses, spread globally, to collaborate on any centralized workflow or tool. In addition, organizations that outsource projects must decide how best to work with third parties. Lastly, some enterprises that invested in project management offices (PMOs) to take on portfolio responsibilities cut these programs when they are too slow to show meaningful results.
Another paradox needs consideration. Tools for managing ideation and innovation practices rarely have full portfolio management capabilities, and portfolio tools may not be the most user-friendly option to oversee ideation, innovation, or R&D pipelines.
Finally, project managers are often barriers to portfolio management when it’s viewed as an administrative reporting tool. If the tool is also forcing them to replicate information that they use to manage projects or, worse, if management is asking them to standardize on tools that they don’t prefer, then project managers can become the most difficult to win over.
So, lack of top-down support, complexity with regard to which technologies to use and how to configure them, and lack of organization alignment often lead many enterprises and businesses to complacency when it comes to portfolio management. It falls into an it’s-too-hard-and-not-worth-it bucket, so they don’t make tracking initiatives an organizational priority. They may capture high-level strategic priorities but leave it to individual leaders and businesses to manage the rest.
Looking at technology departments as a starting point, relying on ad hoc portfolio management practices doesn’t work very well, and it becomes a real issue when additional investment is needed for transformational programs. Technology is partially about “running the business” and “keeping the lights on,” but even operational teams have to take on initiatives. Many are small and scheduled like patching servers; some require investment like when storage is upgraded; others require business participation like when an enterprise system is upgraded; and others may be transformational, such as deploying new mobile capabilities that change workflow. These need to be scheduled, funded, resourced, and managed.
But digital transformation brings on a new wave of projects that have technology enablers, require new digital workflows, and ideally have new ways to service customers. They include integrating marketing automation tools, deploying upgraded mobile applications to customers, or enabling new data analytics capabilities through Big Data technologies. Initiatives that deliver new products require the participation of marketing and sales teams to be trained on the product, develop marketing plans, and establish sales practices.
I ask you, how is the CIO or CDO going to prove that the organization can execute a transformation strategy? How is she going to demonstrate where the organization can execute and where they need outside expertise and capabilities? How will executives know when an initiative is on course, is falling behind, needs outside assistance, or needs additional investment? What is the organization’s single point of truth to view these activities and make decisions on?
This isn’t just an IT need. Maybe some of the low-level IT projects have little business participation, but many of the examples I listed either need to be led by or have heavy participation by business leaders. How can executives know that their best business resources are aligned to the most strategic initiatives? Only if the other projects, the ones that do not require any IT role, are also represented in the portfolio so that resource alignment is holistic. In addition, it works only when the portfolio shows the scope, status, and resources in both IT and in business groups. It’s only then do we see a business/IT alignment that has the best chances of executing on the most strategic projects.
In summary, here’s why portfolio practices are important for transformational programs:
Some of the best ideas come from employees and are not top-down driven from strategic priorities.
Organizations need to pivot, speed up, slow down, and stop initiatives with more frequency and agility as market conditions change, new customer opportunities are discovered, and competitive threats become disruptive.
Most strategic initiatives can no longer be executed well in silos and require staffing, expertise, and operational changes in multiple departments.
Improving customer experience is not just about front-end customer interactions. Organizations also need to consider how to make operations more responsive, how to make data more accessible, how to address security or compliance requirements, and how to drive out costs to succeed at transformation.
Portfolio management practices fail because organizations try to implement too much capability with too many people in their organization too quickly. It’s that simple. Because the efforts to centrally manage the portfolio tend to be top-down driven, the tools selected, workflows created, and rollout processes designed all aim to get the whole organization on board with the program. In doing so, they tend to bundle too many capabilities into the system and workflow up front and try to get people to adopt. The more capabilities and the larger the number of people, the greater the likelihood is that these initiatives will fail.
Technology vendors haven’t been very helpful in this space. Enterprise project portfolio management (PPM) tools look and act like micro-ERPs and require significant configuration to adapt to different enterprise needs. Enterprises go through lengthy technology selection processes, then need to assemble teams that can determine the business requirements for portfolio management, then develop workflows that are easy for users to adopt, and then the team must figure out how to roll out and train users.
By the time the tool is rolled out to users, there’s already a heavy investment in the implementation. At that point, change resistance emerges because working teams probably have some form of project or portfolio management process. It may be a bunch of spreadsheets or a PowerPoint, but to these teams, it’s “good enough” for them. Lastly, by the time this is all completed, you may be several months into developing portfolio practices, and the sponsoring executives are likely to be well beyond frustration.
The centralized PPM system comes across as a complex, bloated administrative system. It takes significant time to get data into the system before its reporting and analytics capabilities become useful in decision making. But therein lies the final drawback: It becomes useful only if there is reasonable data governance in how individual project managers and teams use the system. Where there is inconsistency, any rollups or aggregation may enable decision making on low-quality, incomplete data.
Bottom line is that top-down, large-scale rollouts of portfolio management practices don’t work. They take too long to configure and are too complex to roll out department by department. If you are in a command-and-control organization (which has lots of other issues), then maybe you have a shot at making this work using the stick. But here’s the catch. It’s hard to develop standards and enforce data quality if you roll out portfolio practices too quickly and without working examples.
Is there another option? Where can we draw inspiration from when we need to roll out an enterprise practice?
When Yahoo launched, it was a simple-to-navigate directory. Google was a search box and a button. LinkedIn enabled you to upload your contacts. Facebook first rolled out to college students only. Twitter started with 140-character text streams. What these consumer sites understood is that they had to do something fundamentally important in simple ways to get early adopters.
Social and collaboration tools usually follow a simple 1-9-90 paradigm1 in user adoption. Typically, only 1% of users tend to be “contributors,” 9% contribute passively, and 90% are information consumers or lurkers. Networks cultivate the 1%, especially if they are socially influential to drive content creation and adoption.
Many of you fall into the 9% of casual users when you post an occasional photo on Facebook or “like” an article on LinkedIn. The 9% will be influenced to contribute when a crowd is already participating and there is some benefit to their contributing. These contributions are also sought out by social networks because it gives them more authentic contributions (some of the 1% are self-promoters), and it enables them to have greater reach and relevancy to the last segment.
The 90% are consumers. They read the news on websites but never comment. They network on Facebook but rarely post a status update and almost never comment. You’re sometimes lucky to get an emoji reaction from them.
For ad and subscription business models, getting this model is a good enough start. Even though 90% of users aren’t active contributors, if the content is compelling and these users spend time on the site, then the network benefits.
Enterprises have this challenge of getting adoption and collaboration from larger percentages of employees compared to social network users. Enterprises won’t be successful leveraging a CRM system with only 10% salesperson participation, so they use several tactics to ensure high levels of adoption. Best practices require executive sponsorship and tying sales compensation for both results and adherence to sales practices. Enterprise human resource functions require employees and managers to participate in performance management processes, and bonuses and promotions are usually tied to information put into these systems.
Enterprises can elect to implement strict, top-down governance to implement portfolio management tools and practices. That’s one approach for command-and-control organizations, but there is an alternative, more collaborative approach to engage the organization.
What enterprises need to learn from social platforms is to start with small ambitions, less functionality, and targeting early adopters. Invest the upfront effort to get something working with a small group and a subset of functionality, then look to grow usage and capabilities over time. These social startups also recognize inflection points when they can accelerate growth, quickly add a new differentiating capability, or look to pivot when something isn’t going as planned. Sponsors of projects targeting enterprise adoption should adopt similar philosophies and practices to enable the high rates of participation required for these tools and practices to be successful.
The secret to developing the portfolio is starting small, gaining adoption and strong results from this group, then growing usage and functionality over time. I’m going to lay out the process I’ve done in three organizations to get basic portfolio management kicked off in the first 30 days of being a CIO. The heart of this practice is to make a 1.0 version so easy to use that it’s criminal for any leader not to participate.
The rollout has five key steps:
1.Capture basic data on initiatives that are active or being planned.
2.Define your data integration process.
3.Identify and configure a portfolio management tool.
4.Gain top-level support for the program to enable you to scale it to other departments.
5.Run your rollout plan.
As with any process, the devil is in the details.
The first step starts where I began this chapter, soliciting some basic information across the organization. What you’re looking to do is to understand what projects are in flight, what is their current status, who is leading them, what the strategic drivers are behind the project, and what tools are being used to manage the project.
You’ll notice that I use the word “initiatives” more than “projects.” That’s by design. Projects imply there is a start and end, whereas I steer most of the work toward agile programs that might have a beginning but then go into a phase of ongoing investment, not an ending. I like calling these agile programs.
Also, the word “project” makes some people quickly seek developing an end to end largely scoped project plan. This isn’t ideal for agile programs, and is equally problematic for transformation programs and strategic planning exercises where a steering meeting must adjust priorities as they evolve their thinking.
Over time, I’ve used the more generic word initiatives to encompass traditional projects, agile programs, strategic planning, and all forms of activity that are non-operational.
That’s my minimal data gathering exercise: answering the basic question of what project, who is in charge, what is the benefit, what stage is the project, and where can one go for more information.
Before embarking on this data gathering exercise, you’ll need to better define these fields and decide whether these are sufficient.
What project?—I require a short title. 140 characters max. Something that I can skim and read.
Who is in charge?—I would suggest collecting email addresses for this field so that you have ways to look up additional information in your enterprise directory.
What is the organizational context?—If you have multiple businesses, product lines, geographical centers, and other organizational context, then implement the minimal taxonomy so that you know the context of the initiative.
What is the benefit?—Figure 4-12 shows four basic types that are driving either revenue, cost savings or longer-term strategic needs. You’ll have to decide whether these definitions are sufficient for your organization, but I would urge you to keep this simple. If your definitions are too granular, it will force participants to have to think a lot about how to best characterize their projects. More thinking implies harder to fulfill and less likely to capture sufficient data.
Figure 4-1. Types of initiatives that drive ROI, enable new capabilities, and address risk
You’ll also have to decide how to respond to participants when they say that an initiative supports multiple strategies. If your tools enable you to collect multiple selections easily, then you can look to support multiple options. If you have a small number of types, then you could look to collect them as separate fields and ask for more qualifying information. So instead of selecting “Revenue driving,” you could replace it with “Target revenue over the next three years” and Operational Efficiency with a similar metric on expected cost savings. While this is possible, I don’t advise it because this adds to the complexity of collecting data, and it’s likely that a single field of more detailed information isn’t sufficient anyway.
Network—Where I can get more information is ideally a link pointing to a document folder.
Stage—If your organization doesn’t already have a formal way of defining the stage of an initiative, then this is where you’re going to have to propose one. I typically use the definitions in Figure 4–2.
Definition |
|
Defined |
A placeholder with no formal work done on it |
Ideation |
An idea that has a founder developing its business case |
Planning |
A business case has been established, and a small team is developing a businesses and execution plan. |
Development |
Active resources working on the initiative |
Operations |
Initiative is operational. The working team is taking steps to ensure success criteria are met and working on continuous improvement priorities. |
Done |
Success metrics have been documented, and the initiative was closed. |
Figure 4-2. Initiative stages from definition to done
If you have a smaller organization, then there may be room to collect additional information that will help rank, group, and sort projects. But I would be careful about adding too many fields that may result in overwhelming or scaring off participants. Some possible options:
More detailed description of the project and its benefits
Planning questions that help steer planning teams to what open questions exist and should be addressed to validate the business plan assumptions
Quantified revenue or cost savings targets—either year one, three-year, or multiple fields
Strategy alignment dimensions if your organization has announced specific strategies
More detailed resource information: Who is the sponsor? Who is on the initiative’s leadership team?
More details on initiative milestones to help develop enterprise calendars
More specific details on whether and how the initiative requires any capital investments, new technologies, marketing activities, or needs from any shared services
Link to any project management tool being used to track tasks and milestones
Once you know what data you are collecting, you should decide an appropriate tool and process for collecting the data. You might have different strategies depending on how many people you are asking to participate, how many fields you are looking to collect, and whether the data already exists in another tool or needs to be created from scratch.
Organizations that already have some form of project tools in place can likely extract some information and fill in the gaps required for the portfolio. These organizations are going to want to specify both a data feed format and a spreadsheet template so that participants can share data.
Recall that in the last chapter, I highlighted data integration platforms as one of the key technologies used in transformation programs. This is a good example of where it can be applied. So ideally, if data already exists in another platform, consider how to automate pulling it, what data transforms are required, what quality validation is needed, and how to handle exceptions.
If you’re building a portfolio from scratch and there are few tools used for managing projects, then you’ll likely want to skip this step and focus on selecting and working with a portfolio tool.
Once you know the data, then you can consider what tools you want to select, configure, and deploy to manage the portfolio. Here are some considerations:
The portfolio must support the lifecycle of initiatives. Initiatives are created, move through stages, and some will be marked done. Some initiatives will start, pause, restart; others may get fully cancelled somewhere in its cycle.
A portfolio does not replace tools used to manage agile initiatives and other types of projects. If you are a large organization, you’ll want to consider whether you want to integrate data from these tools rather than force participants to rekey data. The more projects, the fewer tools, and the more data available in these project management tools, the more likely it is that you’ll want to consider whether you can automate some data integration.
Consider UX capabilities of platforms. No one wants to click a lot to perform basic data entry. You’ll want forms that can be configured to handle different use cases and grid entry so that batch entries and updates are easy. You may want to allow users to export, modify, and import.
Make sure the tool allows you to track changes and approve ones that are significant. You probably need some controls to manage moving initiatives from one stage to the next and don’t want participants to stage themselves.
Make sure searching works well. If you’re implementing many dimensions, then your tool should have easily accessible UIs to help drill into results. Modern tools should have faceted navigation and rely less on “advanced search” capabilities.
Consider reporting needs for participants, leaders and executives. You’ll want to make sure your portfolio tool has APIs or ODBC to enable external reporting.
Develop a list of workflows and tools that don’t exist in the enterprise and might be good enhancements to the portfolio. The next section has examples like centralizing status reports, tracking project costs, or engaging the organization on new ideas.
These seem like relatively straightforward requirements. You would expect that portfolio management tools should be able to support these requirements.
My experience is that this isn’t the case. As stated earlier in the chapter, one chief reason why portfolio management often fails is that the tools selected are either too cumbersome to configure, have clunky user experiences and are too difficult to use by participants, or are too closed, making it difficult to import data or plug in external BI tools. If the administrative overhead to build, support, or use these tools is high, you’ll never get the adoption. If the data collected and the workflow configured isn’t developed to the specific needs of the organization, if it’s too out-of-the-box, it will fail to deliver sufficient value, and the initiative will lose momentum.
It is for these reasons that I always elect to build rather than buy portfolio management tools.
But I don’t build them from scratch. That would be too expensive to develop and maintain. The minimal portfolio I described is essentially a single table. You could build this capability in a spreadsheet, a MS SharePoint list, or even a simple database. But add in the next level of capabilities, and now you’re going to need an application that supports multiple workflows and a larger data model. If you go down the home-grown route, it is very likely that you will need to dedicate development resources to maintain and extend capabilities. Most organizations can’t afford to make this ongoing investment, unless the development is very inexpensive.
There are options to build custom applications rapidly and at low cost. These are so-called low-code platforms that enable developing web and mobile applications without the need to write formal software code. These platforms tend to be Cloud based and support limited workflow capabilities but still enable a wide range of lightweight organizational and departmental development needs. Some of these platforms are simple enough that they enable “citizen development,” that is, applications, workflows, knowledge databases, and other tools developed and fully supported by business end users with minimal or no assistance from development teams. For many organizations, these tools are perfect for developing an organization-specific portfolio.
If you have a larger organization with more specific workflow needs or if the portfolio must comply with specific regulatory environments, then you can look at Business Process Management (BPM) tools to develop the portfolio. The downside of these tools is that many BPM tools are designed to be configured by application developers, so while this might be more efficient than developing a proprietary application, you’ll still need to allocate development resources to in order build, support, or extend portfolio capabilities.
I have yet to meet a CEO who fully “gets” centralizing initiatives. They get it to a point but rarely understand all the value it brings to aligning teams and optimizing resources.
So having a prototype of the tool helps, especially if you can get some participants to input data. I’m not saying you’ll be fully successful getting the CEO on board with a prototype filled with data, but the CEO will not see the value without a demonstration of how the portfolio will enable smarter investments and better execution. Don’t forget to highlight simplicity because if the CEO associates the portfolio with bureaucracy and additional administration or if it resembles a previous attempt to establish PMOs, then you are likely to get bounced without the required support.
If you fail, your fallback is to launch it to your group as a beta. Guess what? That’s more or less how I’ve rolled this out in my three trials, but it still pays dividends, and eventually you will get some support even if portfolio practices aren’t fully embraced across the enterprise.
This step will help you determine your charter and scope. If it’s embraced, you should prepare to roll this out to a wider net of participants and demonstrate its simplicity and value. If you’re starting with your team, then you can focus on process mechanics and governance more than value proposition.
Regardless of your charter and how much data you’re successful capturing up front, roll out your portfolio tool as you would any other enterprise tool. That is, roll it out as slowly as you can to get more volunteer adoption, to knock out any kinks in workflow, and to make sure you’re getting the targeted data quality.
I’ve always kept the initial configuration incredibly simple because, in my experience, these tools need to roll out very quickly. At one CIO position, after showing the tool to the president during my second week in the role, he asked me to lead a prioritization exercise across the senior team at an offsite scheduled for the following week. In another role, we had to use the tool in month two to aid in a restructuring. In my third, we needed to define a charter for a transformation program and align resources very quickly to meet year one targets. If you keep the initial portfolio capabilities simple, you have a much better chance of demonstrating value.
Focus your rollout on the following principles:
Make sure participants understand why you are taking on this exercise.
Make it clear that this isn’t a onetime effort and that they will be expected to participate.
If your tool’s user experience is cumbersome, strongly consider alternatives before you get started. Similarly, if using the tool requires a lot of training and isn’t intuitive, you’d best slow down and look at other options.
Ensure that data definitions are well documented and that the data quality targets are identified as success criteria.
Encourage supporters so that you can use their efforts and results as examples to others. Let extreme laggards be laggards, and align them over an extended period.
Set expectations on what you want participants to do in the tool and set a cadence for these updates. Expect to nag participants until using the portfolio becomes part of their habits.
Once you have a basic portfolio in place and even if it’s limited in scope it’s time to add some capabilities that make it more useful. Remember, when you add capabilities, steer away from ones that are too complicated or replicate too much information that is already in project management and other tools. Continue to think of portfolio as a high-level aggregation tool that enables both decision making and collaboration.
The following sections describe a few capabilities that I have developed over time at three different organizations to various degrees of capability. I’ve always rolled out Status Updates, and these were foundational in my organization’s ability to manage many active digital transformation initiatives. Smaller organizations may find value in using the tool for ideation and for resource management, so I’ve included some details on these workflows. Other workflow options include vendor management, hiring workflows, contract management, and asset management.
It drives me nuts to see project leaders send out updates on their initiatives by email—all that important knowledge buried in an email system and available only to the email recipients. Even worse are status updates delivered in MS PowerPoint, the ones that have big bold colors to indicate project status. While these enforce some uniformity in reporting, they are likely to be time-consuming to fill out and provide limited information to stakeholders. What if I want to observe the trend for an initiative? Is this initiative always status red? Is this leader more likely to label her initiatives red compared to her colleagues who prefer showcasing their projects as green?
Even worse is when there are no standards for updating leaders on the status of initiatives. These organizations operate with little information and request it only at key milestones or at specific organization events. How do leaders ensure that initiatives stay on track and don’t require some remediation if there aren’t regular status updates? What if an initiative needs to pivot, be delayed, or even accelerated? How are leaders going to recognize these needs without basic information?
A worse scenario is long drawn-out status meetings, the ones led by a controlling leader that isn’t information driven, gathers all the leaders (or as many as can attend) into a room to do a readout of their initiative. Even if you only have a few initiatives, say five for example, the most efficient meeting is going to be 30 minutes in length and involve six individuals. Don’t you think the same information can be conveyed a lot faster and more efficiently? Wouldn’t it be more important to use the same 30 minutes toward decision making, planning, or coordination rather than just updating colleagues?
There is an answer, and I call them Status Updates, and here’s how I’ve implemented them. A new screen in the portfolio tool asks project leaders to report a Status Level of red, yellow, green, and a text field captures a three to four-sentence update for each initiative that they manage. I ask project leaders to submit status updates weekly on a specific day of the week and time window. I set this schedule so that status updates are entered the day before any steering or leadership meetings. Reports help leaders view either all the updates for that week or updates for a specific initiative over a selected period.
I convene project leaders to walk them through the process, explain why these updates are important, and demonstrate the reports. I ensure that they understand their responsibility to submit them on time and to accurately reflect the key status of the initiative in language and terms that those not directly participating can understand. Also, I ask them to assign and train a delegate to submit an update for times that they are not available. Make it clear that they should submit even if there’s no material change in status.
You’ll need to nag a few laggards who miss getting there on time and coach everyone on when to set an initiative in yellow or red. Some junior project leaders will need assistance on how to improve their writing and to avoid internal jargon. Some will need guidance on what level of detail to include in updates that reach senior leaders.
Some will want you to formally define red versus yellow versus green status. I try to avoid this as I prefer seeing the leaders self-interpret these status levels. If they persist, I tell them that red means you’ve hit a material risk at missing a deadline, scope of a primary deliverable, or have identified a significant quality issue. They can use yellow to identify risks that the team is actively mitigating.
By that definition, many initiatives should be in yellow for periods of time. That’s a good thing because it keeps the leaders and participants on top of the underlying issues and risks. If you see an initiative with green status for several consecutive weeks, it may be a good idea to take a deeper look and make sure the team isn’t oversimplifying or missing key details.
The best ideas come from employees, right? The salespeople talking to strategic customers, the new employee in operations who thinks there’s a more efficient way to run a key business process, a digital marketer who has ideas on how to better reach a key customer segment, a developer who wants to prototype a new technology, the Compliance Officer who is looking for more support to address a key organizational risk, the administrative assistant who has an idea on how to enable better collaboration with remote workers, or the Security Officer who wants employees to learn about the latest threats. How do you capture those ideas and have the right people put effort into the most important ones?
If your organization is ready to use collaboration tools to capture ideas, then you might be ready to extend the portfolio to enable employees in the organization to submit them for consideration. If you’ve implemented a portfolio with an initial stage “Defined” as recommended, then you can use this as the default stage for ideas submitted.
From there, you should decide what data you want to capture on the idea. There’s an art and a science to this because if you capture too little information, it will be hard to vet the idea without a lot of effort to consult with its sponsor. If you ask for too much information, it will look complicated, and you are likely to frighten off good ideas.
The other variable is how fast you roll this out. Do you share it with the entire enterprise on day one and promote a democratic process, or do you start with a select group and grow with some demonstrated success?
Learning from social startups, I recommend a simple start with a pilot group. The minimal fields I would capture include the Project Title, Who’s in Charge (who submitted), the Organizational Context, and the single field to capture the Benefit. I would then add a single paragraph “Describe the Idea” field that I would limit to 400 words.
I would recommend partnering with head of talent, selecting two or three other leaders to form a steering group, and identifying the pilot group of innovators and change agents across the organization who can submit their ideas. The steering group should review the submitted ideas and assign one of three action-oriented categories: “Worth Considering,” “Hold,” and, “Pass.” The steering group should then identify next steps for each category that covers how to communicate the results to the sponsor and provide guidance on formally moving the top ideas into the portfolio at the ideation stage.
If you have a limited number of resources and they are largely employees, then there’s probably little reason for the portfolio tool to have too much information on resources.
However, if your organization has a healthy mix of employees, contractors, and resources from outsourcing providers, you might find it useful to centralize a small resource database that’s not replicating what human resources captures or what is required in your corporate directory.
There is some useful information for managing a portfolio of initiatives that you may not easily be able to store or access in an HR system, ERP, or corporate directory. You may also find that it is less efficient or reliable to ask project managers to record this information in their project management tools.
What information is useful at a portfolio level?
Resource type (employee, contractor, outsourcer)
Statement of work (SOW) terms such as start/end dates, contract type (time/materials, fixed, etc.), hourly rate
Location
Skills and skill levels
Additional contact information (for example, instant messenger)
Availability calendar (if you don’t have one already)
Links to initiatives they have participated in, roles they took on, and when they were participating
Links to signed contracts
I find that organizations in transformation have a lot of flux in the number of running initiatives, budgets, and resources. Many resource management tools are optimized to handle relatively static resource pools and become difficult to leverage when you need to shift or add resources frequently. Centralizing a basic repository for this information, assigning ownership, and creating some basic processes can accelerate resource management practices in organizations that need to move smarter and faster.
At some point in your transformation, you’re going to have to think through the financial aspects of how you will fund and ultimately drive a return on the investment. Unfortunately, most ERP systems are configured to run today’s businesses and may not have sufficient detail to help model transformation scenarios. That’s not to say they can’t; it’s just more likely that the financial teams only capture information at a high level and not at an operating level. Chances are that your financial system has a lot of detail on employee-related costs and high-level information only on costs tied to contracts, assets, and initiatives.
If you’ve implemented some of the portfolio practices that I’ve recommended, then you’re on your way to capture some of the financial details on contracts (start and end dates, expenses, classifications) and external contractors (start and end dates, locations, hourly costs). Hopefully, you have an IT asset-tracking system that also enables you to capture financial details on any infrastructure or software assets. If all you’re trying to do is keep track of existing costs and know when decisions are needed on an expiring contract or an asset going end of life, then you can select one of the many tools that handle this accounting.
But look around your organization and find out how individual departments propose and track their budgets. Perhaps the enterprise has selected a tool or implemented a component in the ERP to propose and then track departmental budgets. But I suspect that many organizations are doing this by working with their finance teams to review and transition costs as they are represented in the ERP from current to next year. Other departments will propose budgets by itemizing the details in spreadsheets. Budget spreadsheets are assembled, details are aggregated, decisions are made, and final aggregated numbers are loaded into the ERP. Once a quarter or month, depending on your organization, you sit down with the finance team to review spend and reforecast.
Budget tracking by spreadsheet is not sufficient for managing technology budgets, for multiyear transformational efforts, for budgets when an organization is experiencing significant growth, or for budgets for organizations that are undergoing a turnaround. These scenarios have a few things in common.
First, the budgeted spend on specific programs, vendors, and resources is likely to change through the year as more details enable better decision making. Most organizations formally budget once a year, yet transformational programs require making decisions and pivots throughout the course of the year. So if you want to make an investment midyear, you probably need a detailed accounting of current spend and forecast to determine where you can shift money budgeted from other programs.
Transformational programs are often multiyear, while corporate budgets follow a yearly accounting cycle. Investments, operational expenses, cost savings, and revenue often cross the accounting year boundaries, making it difficult to track. Eventually, sponsors of the transformation will want to understand ROI, and if you’re relying on information collected in the ERP or data stored in spreadsheets, then you’re going to have some difficulty tracking and reporting financial status.
Transformation programs also often require a spending shift. You might be automating operations and taking cost out, but the IT department needs new funding to support the underlying systems. You might want to boost marketing spend when new products are launched and want to consider curbing costs in other areas to offset.
Organizations experiencing growth or turnaround require looking at expenses across multiple departments to understand where costs can be cut or where growth requires additional resources. If your ERP has detailed scope and reasonable data quality, then this can be the data source for modeling these scenarios. The challenge is having the right tools to be able to model multiple scenarios, do so with frequency, and have a collaborative dialog with decision makers on what levers to pull. Try doing the modeling in a spreadsheet, and you’re likely to go through hours of Q&A meetings with executives pushing for finalized numbers and operational leaders trying to reverse engineer calculations to understand the underlying decision.
There are times when you can make accounting cycles work to your advantage and other times when it can create risk. This is especially important for organizations with tight budgets or managing through a turnaround where every dollar matters. Perhaps it’s better to make a purchase in a vendor’s fourth quarter to get the best discounts? Maybe you are spending less on a contract than forecasted and there’s room to squeeze another project within an existing scope of work? Both scenarios need leaders to track expenses at a detailed level to make tactical financial decisions.
Finally, organizations in transformation, growth, or turnaround should track variable costs at a detailed, operational level to make sounder financial decisions. Maybe there is a variable cost that’s skyrocketing, while a business or operation is scaling and you need early warning signs from operational data before you are invoiced and on the hook for the cost overrun? Maybe there’s a recurring cost for a service that’s used episodically, and it may be advantageous to either renegotiate the contract or find an alternative service? Maybe you’ve surpassed a volume of operational activity, and there is opportunity to renegotiate? Maybe you need new controls to better manage an on-demand service that has significant cost factors? Decisions based on all these factors require a connection between financial and operational data, updated frequently and reviewed by subject matter experts to know when a cost factor requires a review and decision making.
If you’re going to calculate ROI, then you also must project and capture financial benefits. The ERP should be the source of this information, but you’re likely going to need some analytics or processing before plugging this into a P/L for an initiative. Maybe only part of the revenue from a new client can be associated with the initiative? Maybe you need some form of allocation of new customer revenue across multiple initiatives? Tools are needed to perform these allocations and ensure that the underlying calculations are transparent to decision makers.
You might argue that all of this is within the financial team’s domain and they should step up with practices and tools to address it. The requirements outlined illustrate the need for financial and accounting teams to operate in real time with more operating data and with more transparency and collaboration with business leaders. Can they step up?
You’re the transformational leader, so you can decide whether this team, its practices, and its technologies are ready to step up and take on this role. But in my experience, they aren’t ready until you blaze a path for them. These teams are under-resourced and are last in line for technology investments. Few go out of their way to collaborate with them, so it’s unlikely they have access or knowledge of the underlying operational data. It’s also inefficient for you to fully outsource the scenario planning, cost tracking, and reforecasting to them when you manage a transformation program that is likely to require frequent reforecasts, pivots, and scenario planning.
If your enterprise is doing over $500M in revenue, then you should consider leveraging an enterprise performance management application to perform profitability analysis and scenario planning. Gartner has several solutions in their magic quadrant that can likely be tailored to the type of ongoing analysis required for transformation, growth, or turnaround.
I am going to describe the scenario when this isn’t an option. This may occur because your business is too small to afford one of these solutions, if your existing solution can’t easily be used for transformation planning, or if it will take too long for your organization to acquire and configure a solution. This is the situation I’ve been in for my last three CIO roles.
There are three components to a solution that you can easily craft if you have the right basic tools and talent:
A database to track budgets and expenditures
A BI tool that can be used to develop dashboards connecting financial and ERP data
A modeling tool for scenario planning and transitioning financials from current to future states
Let’s look at all three in more detail.
Everyone has a budget spreadsheet. During budgeting season, it’s nicely formatted and well structured to show the expenses, dimensions to help group them, and fields to align them to strategic drivers, owners, and timing. Larger departments will hand out segments of their budget to different owners and roll them up, sometimes manually and other times by versioning the worksheet in a document repository.
When completed, it goes through the corporate scrutiny process. Some items come out, others may get added, some values may change. It gets a little messy tracking these changes, but no one likes long budgeting processes, so hopefully this is over in a matter of weeks.
Once completed, finance has the job of rolling the data into their ERP. As reviewed earlier, most often this is done at an aggregate level. Likely, they will capture several categories of spend underneath every cost center. I have yet to see a finance department capture every itemized spend.
So that leaves the granular tracking to the budget owners. Some will elect to do this tracking. Others will manage to the overall number.
My experience with running digital and technology budgets is that managing the budget at a granular level must happen four quarters of the year. Sometimes I reforecast because the business climate changes or the priority changes, and I’m asked to submit an updated budget. Sometimes variable expenses come in higher than budgeted, and I look for other budgets to cover the variance. Sometimes the budget exceeds the technology organization’s ability to execute, and I can drop the forecasted spend, while other times I want to increase spend where there is opportunity to deliver more value faster. There are times when I need to benchmark spends in specific categories to judge efficiency and need to be able to match spending categories to the ones supplied in the benchmark. Lastly, I need accurate low-level budget information to do bottom-up multiyear strategic forecasts. I likely must do this with a small team of lieutenants who have better knowledge of the various costs in the technology budget.
I’ve used tools outside the ERP to perform budget tracking of transformation programs. The tools have been relatively primitive but much more powerful than tracking budgets with spreadsheets. It’s a second “use case” for the “low-code” platforms that I’ve deployed.
What does the tool look like? It starts with your budget spreadsheet, the neat one that you probably developed during the budgeting process. It then enables the following additional workflows:
Assign an owner to the budget.
Track individual budgeted items that roll up to various spending dimensions.
Normalize a taxonomy for categorizing budgeted items.
Lock the budget at the end of budget season.
Enable workflow to request budget changes, have them approved, and reforecast.
Interface with the ERP to capture invoice data.
This might look complicated, but it’s not if you have a low-code platform. I’ve personally developed this tool three times to efficiently manage transformation programs.
I should point out that in all three instances, this tool, data, and workflow were shared with appropriate finance department members. It has cut down on meetings and complexities to track forecasting changes and enabled them to better accrue for expenses.
Once you have a basic budget tracking process workflow, the next question is how you will report on the data. Your lieutenants need some basic dashboards to visualize spend and make decisions. You may also want to be sharing some of the data in aggregate forms with stakeholders, finance, and executive teams. I have found that providing this level of transparency drives trust with business leaders, showing that the technology team is making sound investments and are managing expenses.
This leaves you with a couple of options. You can either build some basic reporting out of the platform used to develop the workflow, or you can consider a reporting platform that connects to this data. I usually depend using a self-service BI tool for this reporting because it enables connecting to other data sources like the ERP and developing audience-specific dashboards.
Tracking financials and visualizing them are not sufficient. The last mile is putting this data to good use to enable better short- and longer-term decision making. Some examples:
Capture and track ROI against an initiative.
Demonstrate a total cost of ownership of a service.
Reforecast spending under multiple business scenarios.
Benchmark your spending in specific categories.
Model different investment scenarios when multiple solution options are possible.
Show the ongoing operational costs against new investments.
Forecast cost reductions when services or systems are decommissioned.
Model the financial impact of reorganizations, outsourcing, and other strategic shifts.
Implement a cost allocation when a service is applied to multiple business units.
Calculate the impacts of increasing scope or accelerating timelines.
As a CIO, I have been asked these questions repeatedly. In small technology departments with understaffed finance departments, it has fallen on me and select members of my staff to do this level of financial modeling and presentation. So are you prepared to pull this off when you can dedicate only a fraction of your time to do this level of planning?
With baseline data in place and a reporting tool, you’re halfway there. The last mile is to figure out what tool you’ll use to do the modeling on demand or as needed.
This is where you must make some quick calls on the best tool for the job. In many cases, I’m resorting to spreadsheets that connect to the baseline data if I am putting together a onetime or low-frequency analysis. Other times, if I think something is repeatable, I may develop specific structures to capture and track the scenario or enable the modeling as a core capability. For example, ROI calculations are needed in multiple instances, so I am more inclined to develop this as a capability, whereas reorganizations are less frequent and probably best modeled in a spreadsheet. If the presentation can be done largely through calculations and data visualizations, then I will implement it in a BI platform.
I hope this chapter didn’t make your eyes roll. I know tracking initiatives, resources, and financials isn’t the most exciting aspect of running transformation programs or technology organizations. But it is necessary and is far more important in successful programs, especially for smaller organizations where funding is not easy to come by and investments are not easy managerial decisions.
I’ve termed these practices agile portfolio management because they don’t need to be in place prior to kicking off your transformation programs and should be designed to evolve where and when needed. Once you have the foundational structure to capture initiatives and financials and have a pilot team to work with, then you can scale capability and usage as needed.
How do I do this in practice?
I run my management team as monthly agile sprints. Our management meetings respond to “red” initiatives and plan the next set of organizational capabilities. They take the form of retrospectives, so when we discover a governance, practice, process, or data gap, we itemize it in our backlog and decide whether to prioritize its development.
Next chapters start entering the domains of new responsibilities. First, we must look at data, data science, the role Chief Data Officer, and evolving to a data-driven organization. Then we will look at how to develop product management capabilities to drive new sources of revenue and growth.
