A quick Internet search yields lots of great information about the benefits of a Project Management Office (PMO): common processes, improved project selection and oversight, and best practices for everything under the sun that might be related to a PMO. There’s also a lot of good guidance about what you need to do to get started. But before you run off to create your charter, your business case and the presentation materials, you may want to consider if your organization is actually ready for a PMO.
Organizational readiness is the combination of circumstances and conditions that enable the initial formation of the PMO and provide the necessary ongoing nutrients to achieve full potential. In a nutshell, organization readiness means having the ‘right stuff’ to make sure that the PMO will be able to spend its time contributing to the organization’s success rather than just fighting for survival.
Having started more than a few PMO’s myself, I can tell you that the best condition for readiness is ‘need.’ All of us know that want is very different from need. When everyone shrugs their shoulders and sighs, ‘Yeah, we could probably improve our project performance,” or “Maybe starting a PMO might be helpful but…,” it’s highly likely that that the organization is not ready. On the other hand, when projects become a burning platform – with that undeniable set of challenges that are appropriately addressed through the expert application of the disciplines or processes typically found in a PMO – then you’re ready.
For example, let’s say you have a large program or initiative. But it’s not just any large program, this is a large mission-critical program; A program that, if it fails, takes the company’s future with it. You need central coordination and visibility into multiple efforts so that swift and decisive action can be taken as challenges arise. Or, let’s say that you work in an environment where there are a lot of projects going on concurrently and, while everyone is working hard, little gets done. Priorities are unclear and competition for resources is fierce. Management recognizes the problem but can’t seem to get their arms around the situation. In both cases there is a compelling need for what a PMO has to offer, and you’re ready for a PMO.
Something else to think about is the breadth and level of organizational support. In my definition, organizational support means more than just lip-service. True support means that the PMO stakeholders recognize and can defend the value of the PMO. It also means that those stakeholders across the impacted organization are willing to participate in the formation of the PMO, contribute to the design of PMO processes and standards, and support the application of and adherence to those standards over time.
While we often recognize that this kind of support is important from our executives, we underestimate how important it is from peer groups within the organization. After all, these are groups that the PMO ultimately depends upon for the resources and information it needs to accomplish its mission. If these groups aren’t ready and willing to play, there won’t be much of a game. The PMO will be relegated to the role of ‘Process Police,’ spending more time chasing down data, documents and people than adding real value. Or even worse, the PMO will be perceived as the ‘Prevention of Progress Department’ – additional overhead without any real benefit.
Last but not least, organizational readiness for a PMO is tied to organizational will: Once your organization has a PMO in place, are the decision-makers going to make the decisions needed to realize the benefits? If a project is inadequately justified, poorly defined or badly managed, is someone going to be willing to say ‘Stop’? If we provide information that clearly shows we have inadequate capacity to execute all of the projects that we want to do is someone going to make a decision about what we are not going to do? The best PMO in the world can’t be successful if decision-makers can’t or won’t decide.
So are you ready for a PMO? If you don’t have clear need, support and will, it’s highly likely that starting a PMO will be an uphill battle and, even if you can pull it off, success may be short-lived. If you already have a PMO without need, support, and will, it may be time to make it a priority to get your organization ready for what it already has. Been there. Done that. Good luck!
The role of the PMO has become more critical than ever in supporting strategic business priorities. As PMOs become more successful, they also need to be more accountable and prove their value. In this blog post we outline our top 10 metrics to track PMO performance. Although a PMO may not be able to track all these metrics immediately, as a PMO grows and matures, it should be able to track the majority of these metrics on a quarterly performance scorecard.
We’ve organized the ten metrics to map to four business drivers of a PMO: (1) Strategic Alignment, (2) Operational Efficiency, (3) Execution and (4) Business Value Delivered.
1) % of Projects Aligned with Strategic Objectives. The number of projects, or weighted cost of projects, that are aligned with at least one strategic objective over the total of projects.
2) Investment Class Targets ($). Set investment targets for Run, Grow, and Transform type of projects and analyze spend variance against these. A simpler alternative is to report the percent of effort/cost going toward ‘Keeping the Lights On’ (KLO) activities for IT.
3) Business Unit Investment Targets ($). Set investment targets for cost and effort devoted to each business unit and analyze spend variance against these.
4) % Resource Utilization. The percentage of time spent on productive activities such as project work, ticket resolution, etc.
5) % Project Effort. For IT PMOs, the percentage of time spent working on projects, as opposed to maintenance, enhancements and tickets. This should be measured against a target to show delivery of new business/technology investments.
6) % Project Churn. The number of projects put on hold or cancelled over the total number of projects in a given period.
7) % Increase in Project Success Rate (or % Decrease in Failure Rate). This assumes success is defined not just by time and budget, but by delivering the business requirements (based on satisfaction surveys of the business stakeholders post-delivery).
8.) Variance to Budget ($). Cost savings measured by positive variances to budget. This assumes project costs are accurately estimated during planning. Earned Value can also be used for this, for instance looking at the % of projects with a Cost Performance Index (CPI) over 1. CPI = Budgeted Cost of Work Performed (BCWP)/Actual Cost of Work Performed(ACWP). BCWP is Earned Value (this is the PMI definition). PMO will need to monitor CPI on a per project basis.
Business Value Delivered
9) Customer Satisfaction (%). A measure of stakeholder/customer satisfaction of business value delivered based on surveys post-delivery.
10) Business Value Realized. Business value is realized when the right projects are selected and executed at the right time. Selecting the right projects involves estimating Economic Value Add from a project. This is best if based on actual benefits measurements post-project, but in reality the estimated benefits are simpler to calculate tied back to the project delivery date. This can be measured in cost savings, additional revenue, increased customer satisfaction etc. A standard scoring model can be used to normalize across different benefits, and business value points used to demonstrate value delivered.
In future blog posts, we’ll dig into some of these metrics in more detail. Are there metrics you use that you’d elevate to the top 10?
If this week is any indication, 2012 is shaping up to be the Year of the PMO.
A recent survey from project management firm PM Solutions found that PMOs are becoming more influential and entrenched than ever. The “State of the PMO 2012” survey reached out to more than 500 project managers across a number of industries and saw that, in general, PMOs are playing a significantly larger role in strategic functions, putting greater visibility (and greater pressures) on their success. PM Solutions noted that over the last 12 years the number of organizations with a PMO grew by 40 percent – from 47 percent in 2000 to 87 percent in 2012.
Ultimately, this survey reinforces what Daptiv is hearing from our customers – PMOs have become a trusted advisor in the enterprise and must lead the way to enable intelligent investments and cost optimization. They’re making good traction, according to the survey:
• 30% decrease in failed projects
• 25% of projects delivered under budget
• 22% improvement in productivity
• 19% of projects delivered ahead of schedule
• 31% increase in customer satisfaction
• 29% improvement in projects aligned with business objectives
• Cost savings of US$411K per project.
It’s increasingly important for PMO leaders to partner with and provide C-Level executives with the right project intake process to pick investments that will align with this strategic imperative. Indeed, the survey found that PMOs are moving up within many organizations – with 66 percent of PMOs surveyed reporting to an EVP or higher.
Last November, Daptiv forecast that in 2012, organizations would take a more holistic view of their business by using PPM tools to manage end-to-end service portfolios, product delivery, application lifecycle management, and change management programs. Again the PM Solutions survey found that those PMOs managing what were perceived as high-value tasks such as portfolio management were given increased responsibility and viewed as being significant contributors in spearheading significant new initiatives.
We’re only one quarter into 2012, but the stakes are clearly being raised for PMOs to continue delivering in terms of supporting both strategic business goals and the bottom line.
The role of the PMO has become more critical than ever – how has your PMO evolved over the past year?
In the last couple of posts, we’ve written about the challenges of providing information for decision-making. From collecting data to converting the data to information that tells a story, it’s all about making sure that we’re providing decision-makers, including ourselves, with what is necessary to make solid, fact-based decisions. But there is one more variable we need to consider: what is the best way to communicate that information?
The channels used for communicating, as well as the form and format in which the information is presented, influence both the decision-maker and the decision. Besides concerning ourselves with the ‘what’ we need to consider the ‘how.’ How can we present the information in a way that assures timely receipt and accurate interpretation?
If you’re like me, you receive and send information for decision-making in lots of ways: emails, reports, presentations and meetings. While each of these can be effective, in the aggregate we find ourselves bombarded with information from all directions. While some of the information is useful and relevant, some is not. Some is clear and well-presented while some is fuzzy and ambiguous. Some clearly identifies what action is required and some is just ‘FYI.’ Figuring out what information is significant and what is just ‘noise’ is not only time-consuming; the noise can often drown out what is really important.
As with any problem, recognizing that there is a problem is the first step. But if your job is about providing information how can you reduce the quantity, increase the quality and truly make information a tool for decision making?
Think about one decision that you need to make on a regular basis. Now close your eyes and imagine that the all the critical information you need to make that decision is in one place and, at a glance, you have what you need to understand the situation and make your decision. In your mind’s eye you are probably envisioning a dashboard. And you’re not alone. It seems like everyone is asking for dashboards these days. But just as throwing a bunch of ingredients in a pot does not always make a tasty dinner, jamming a bunch of information on a page does not necessarily make for a good dashboard.
A dashboard is essentially a mechanism for providing a lot of information in a single place. It contains the dials and indicators that provide information about what is happening and where decisions or actions are required to either get things on track or keep them on track. Consider the dashboard in your car – it’s a single location where you can quickly get information about most everything you need to know to operate and control your car when you’re on the road. Through the windshield you can see where you’re going and any obstacles or hazards in your way, the speedometer helps you control your speed, the odometer can tell you how far you’ve gone. There are also a variety of indicators that light up to indicate when corrective action is needed like low oil pressure, or that your engine is overheating. While there may be a lot of other things going on in and around the car, the instrumentation on the dashboard is designed to show you only those things that are important or ‘key indicators’ that are most critical to the operation of the car. There are a lot of other things it could tell you, but it sticks to those things that count.
In addition to showing you what’s most important, each of the dials and indicators has a corresponding set of decisions or actions associated with them. If the speedometer indicates that you’re going too fast, you lighten up on the gas pedal. If the oil pressure light comes on, you pull off the road and turn off the engine. If the ‘check engine’ light comes on you check your bank balance and call your mechanic….
Just as a lot of thought goes into designing the dashboard in a car, there are important considerations that go into designing a dashboard report. First and foremost, you need to remember that one size does not fit all. A number of years ago I had an opportunity to ‘fly’ a commercial jet in a simulator. The first thing that struck me as I sat in the pilot’s seat was the mass of instrumentation on the dashboard – nothing like the dashboard in my car. Why? Because flying a plane is different than driving a car – a pilot makes different decisions than a driver hence different information is needed to inform those decisions. Likewise, managing a corporation or a division is different than managing a project. As long as the decisions are different, the dashboard needs to be different.
Once you’ve identified the audience for your dashboard you need to understand both the decisions that are being made and what key indicators would suggest that action is required. If you are designing a dashboard for a group of executives managing a project portfolio, keep in mind that managing a portfolio is about managing a set of investments. The decision-makers need to know what those investments are, how they are performing and make decisions about reallocating or reprioritizing those investments to meet the organization’s goals for realizing return on those investments. In this case your dashboard may include things like the performance of different categories or types of investments (projects), how much money is being spent in different categories of investments, and what return you are getting from the investments already made. If you’re designing a dashboard for the members of the project team, your dashboard is going to be more focused on the tactical items that help the team member prioritize and focus their work – what is overdue, what needs to get done today or this week, reminders about upcoming events or milestones.
Your target audience can also tell you a lot about the best way to present the information. Typically we like to use graphs and colors in dashboards because one picture, colored dot, or downward facing arrow can convey a lot of information in a small space. But as nifty as graphics and colors are, they may not be informational to the user. For example, in the team member’s dashboard a graph showing the number of their overdue tasks by week since the beginning of the project is not as useful as a short list of the overdue tasks for this week.
You also want to be mindful of how you use the space on the page. The best dashboards are easy to read and use the white space on the page to clearly separate the information so that any given indicator can be located and read quickly. You also shouldn’t need a magnifying glass to read a list or the labels on a graph – just because the software you use to generate your chart allows you to set the font size on your labels to 2 point tiny-type, doesn’t mean that you should use it.
Last but not least, don’t forget that for many decision-makers more detail may be needed to make a well informed decision. Here the dashboard provides the launching off point, but the underlying detail needs to be as readily available as the dashboard. I’m very partial to dashboards and reports that provide the ability to ‘drill through’ into more detailed information. For example, if I’m managing a portfolio of projects and one of my investment categories within that portfolio is not performing well, I might want to drill through to see which projects are contributing to the problem and why. What was important on the dashboard was recognizing that action is needed, but the detail needed to decide what that action is going to be is also readily available. It’s really like that ‘check engine’ light in your car – if it goes on you know you need to do something, but what that something is may require further action. On the flip side, if the light stays off you can just ignore it.
Dashboards are a great way to help reduce the ‘noise’ and help individuals focus on the information that really matters most. If you’re designing and building dashboards, you’ll probably need to go through a few iterations with your stakeholders but the results are well worth the effort. Just remember – NO TINY-TYPE!
This is part two in a three-part series discussing the importance of portfolio planning. This series provides insights on portfolio management best practices in process, metrics and reporting.
When organizations set a budget they typically go through a process to essentially build lists of things that they need or would like to get accomplished during the budget cycle, assign a cost to that activity, and go through some prioritizing to get to the total assigned number. Whether you know or not, if this sounds like a process you have then you are executing a non-structured portfolio activity.
This old-school process has been successful for decades, but with today’s pace of business and the impact of macro-environmental change, organizations need to build processes that are more responsive to that change.
Recognizing this, organizations are beginning to evolve and adopt portfolio concepts. However, these efforts tend to lag, mostly due to a focus on improving the prioritization process and fall into some classic pitfalls:
- “We’re overworked.” A tendency to focus on capacity first. Although I argue that capacity is one of the constraints in portfolio management, initiating planning exclusively to focus on managing capacity is froth with errors. Organizations focused exclusively on workload have a tendency manage resources at a micro level and that just isn’t sustainable. I once had a client that when he moved his focus from matching capacity to demand and focused on the right things, the dialog changed and he became more connected to the business. Dialog between the organizations ensued that actually increased the quality of business outcomes.
- “Emotional” I call this prioritization without principles. Without a framework to evaluate an investment, it always ends up that the individual who screams the loudest, has the best presentation (sales skills), or was the last one in with the bosses won.
- “We’ve already spent the money.” It’s OK to hold or cancel and investment when change happens – It just makes good business sense. When an organization doesn’t hold or cancel a project, when it’s not the “right thing” and the investment resources are tied up in the wrong projects, that’s a lost opportunity.
- “We don’t revisit the evaluation criteria.” This is the one that really frustrates me. Just because it worked three years ago doesn’t mean the criteria is still valid. In reality this criteria not only reflects current business climate, it also represents the decisions we made in the past. Good governance always validates the criteria before anything in the portfolio.
- Lack of Investment Selection Cycles. Once a year (budget time) really is no longer valid. An organization needs to match their investment selection cycles with the velocity of their executing projects. In other words, if the majority of your projects are short term, then more frequent cycles are required. If, however, the majority of your projects are multi-year then a minimum of four times a year should be sufficient to just validate the investment outcomes are still desirable.
- No Formal Investment Governance. Governance provides transparency. We now know (during the recent economic crisis) without proper transparency, investment chaos ensues.
- Everything in the Same Bucket. If we only work on the highest priority projects, then quality/value of lesser priority assets will erode to a point of being a liability to the organization. Having a well thought out diversified project portfolio insures that organization remains healthy.
Non-structured portfolio activity is unavoidable, but knowing what to expect and understanding the potential pitfalls related to portfolio planning will help you plan for and address them in advance, keeping your portfolios on track—and saving valuable time and resources.
In Part III of Portfolio Planning, I will demonstrate the portfolio lifecycle and the key characteristics of the framework.
Back in November, I gave a presentation to an audience of PMO practitioners at PMO Symposium on the reality of putting theory into practice—the feedback was fascinating. While I knew how rare full life-cycle portfolio management is, the audience feedback confirmed that fact and the reasons.
In brief, portfolio management can be broken down into three parts: 1) Portfolio Planning, the process by which projects are selected and placed on the active portfolio, 2) Portfolio Monitoring, the practice of reviewing the active set of projects to ensure balance and performance, and 3) Portfolio Results (aka Benefits Realization), the practice of measuring the return on the investments the projects represent.
I asked the 100+ PMO directors, managers, and other practitioners in the room to raise hands for each practice they have actively in place. As expected, almost all hands went up for monitoring, a little more than half went up for the planning processes, but only two hands were raised for Portfolio Results. That’s two percent in an admittedly non-representative sample. Non-representative in the sense that the attendees at the Symposium are the more mature PMOs!
So what’s going on here? A look at each piece brings the problems into focus.
Portfolio Monitoring at its most basic is simple to implement and provides a lot of bang for the buck. Simply listing all active projects and tracking their health gives executives a much better view of where the money and resources are being spent, allows them to re-allocate if needed, helps them provide visibility to their business colleagues, and allows them to manage performance by exception. Most of this work can be performed by the PMO and project managers, with the results distributed to all stakeholders.
Portfolio Planning requires a bit more effort and requires stakeholders to actually get involved. Many companies have serial, or ad hoc, demand management processes. This path of least resistance requires specific steps be followed,—such as a business case, formal review, and funding approval—be followed. However, by not comparing all requests, serial demand management suffers from prioritization issues and project churn, often since higher priority projects interrupt already approved lower priority projects. By show of hands, this was the most popular, though definitely not the majority, method in use by these PMOs.
Cyclical demand-management reviews on a regular cycle – often monthly or quarterly –forces project stakeholders to compete for resources to support them where a cross-functional steering committee often makes the final decisions. The result is a high-priority portfolio where investments are strategically aligned with corporate objectives. The roadblocks center on getting those cross-functional reps engaged – and getting reps that can actually make decisions!
Of all the components of portfolio management, one would think results would be the most important. And most everyone in the room felt the same. So why is it so rarely practiced? In a word: accountability. To work, business sponsors need to not only to present a business case, but propose metrics that actually get measured post go-live. These measurements might be taken in increments for months or even years in order to fully understand the impact of a given project. Turns out business sponsors know they need certain work (aka projects) performed, but don’t want to take the time for full ownership of the results.
How did the few that successfully implemented benefits realization manage to overcome this organizational resistance? Typically, it was a CEO mandate. Proving once again there’s nothing like good executive sponsorship to drive success.
In this three-part series, I’ll attempt to discuss the importance of portfolio planning and provide some insights on portfolio management best practices in process, metrics, and reporting. I’ll attempt to provide an understanding of why we do portfolio planning, introduce a framework to plan the portfolio and discuss some techniques and guidelines to plan a portfolio.
I have had a number organizations tell me “just give me the process and I’ll execute it,” but portfolio planning is more of an art than a process. Tools like spreadsheets, metrics, scorecards, and investment maps can provide insight based on past experience, but you still need to make the decisions.
Today an enterprise has (or should have) a well-defined strategy that outlines its performance objectives and how it plans to reach them. In order to deliver on those objectives the enterprise organizes into multiple business units or organizations with their own unique operational objectives that contribute to the enterprise. Classically these organizations are focused around the operation of a specific asset type of the organizational value chain.
Portfolio planning is unique to the asset type, the distribution of assets, and to the performance objectives of the portfolio – not all portfolios are the same. For example:
- Enterprise portfolio versus organizational portfolio
- New product development versus IT
- Initiative versus program versus project
- Management of assets versus management of delivery
All of these are important portfolios for an organization; however, for the purpose of this discussion I will focus on an organizational portfolio of projects to manage delivery.
There have been a number of books, whitepapers, vendors and consultants that have provided us the benefits of having a portfolio, but for project portfolio management it boils down to three major points:
- Capital constraints – we’d all like to have a blank check, but we know that’s not practical;
- Resource constraints – not enough or overworked staff;
- Or both.
One of the best references for portfolio management has been the Coopers and Edgett book on portfolio management. Besides the outstanding examples on metrics and other tools for portfolios, the authors were successful in conducting a syndicated study on portfolios and metrics. The study covered 205 companies in North America; mean size of company was $6.4 billion in annual sales.
The conclusion they came to was that companies exceed business performance when the portfolio processes possessed these characteristics:
- Projects are aligned with business objectives
- Portfolio contains very high value projects
- Spending reflects the business strategy
- Projects are completed on time
- No “gridlock”
- Portfolio has a good balance of projects
- Portfolio has the right number of projects
So that’s when it works smoothly. What happens when things go off track? In my next post, I’ll discuss the pitfalls of portfolio planning and address how to keep portfolios on track when dealing with non-structured portfolio activity.
This question gets asked so many times, and the interesting thing is, many of the questioners assume the answer is obvious – though they may come down on different sides of the equation!
In a sense, the question comes from the name Project Management Office, which is a bit of a misnomer given the charter of modern strategic PMOs. Originally, a PMO was a temporary structure that ran the administrative and governance functions of large projects or programs. It lived and died with the life of that project. With that charter, the obvious choice to head the office would be a talented program or project manager.
But the charter has changed. First, the PMO became a permanent structure charged with oversight of all the important projects in an organization. This meant creating a standard methodology, monitoring status, and ensuring projects were executing according to plan while delivering value. This initial type of PMO was still squarely in the realm of the project management discipline.
As those projects were listed and reported to management they became portfolios of projects. Naturally, questions were raised about how projects came to be in the portfolio. Was the list the right list? Was it aligned with strategic objectives? If there were more project ideas than funding or resources, how should we decide which to fund and which to decline or defer? Someone had the bright idea to look at projects like financial investments (which they are, of course) and project portfolio management was born. And investment decisions are definitely in the realm of business planning, not project management.
Then while attempting to ascertain the resource capacity to take on the proposed projects, it became obvious that said capacity was constrained by non-project workloads. So allocating and tracking work across resource pools became a must – and became the purview of the Project Management Office. While program and project management looks at allocating staff across a project or program, this was much broader. Clearly, this is a business resource management challenge.
So now, instead of being a Project Management Office, the PMO has become a blend of Strategic Planning, Portfolio Management, Program/Project Management and Resource/Workload Management.
With today’s modern PMO charter, having project management skills – even if you’re really good, isn’t enough. While Project Management is still one of the charges of the PMO, it’s only a portion – and not the main driver. Strategic PMOs are really facilitators mediating the tough negotiations and decisions about how work is allocated and investments made across a diverse portfolio. If you’ve ever chaired a steering committee meeting full of VPs arguing for their projects, you get the point. If you’ve had those tough conversations with business counterparts about how many resources are allocated to KLO (Keep the Lights On) work, you understand. If you’ve ever tried to answer the “what has your PMO done for me lately” question, you really get it. Thus, the emphasis is on business management, strategic planning, and facilitation skills.
So, do good project managers make good PMO Directors? It depends on the PM. If they are good at understanding business strategies, if they are good at understanding what makes their company’s business model tick, then probably. Of course, we think good PMs are not just task, issue, and risk managers. We think the best project managers are true leaders that know how to lead projects to achieve positive business outcomes. And since they also understand and embrace project management, those project/business leaders can often make strong PMO Directors.
We see many software teams that describe themselves as agile, but still develop project plans, assign resources to tasks and track time on their project. Agile purists would argue these teams are not truly agile because they are breaking some agile principles, such as encouraging empowered and self-organizing teams, and enabling a responsive, efficient development process. Are these teams agile, traditional iterative, or some hybrid of the two?
The reality is many enterprise software organizations are comfortable with traditional project management techniques, but want to move towards an agile development approach. They are typically engaged in project-driven work versus a software product with an unending feature backlog. They also have to contend with shared resources, such as database administrators, network specialists and architects that may not be assigned to their projects full time.
Many of these organizations are moving from traditional iterative development to a hybrid methodology that incorporates some of the best ideas from agile, but fits with their culture and needs. For instance, they will take to heart the principles in the agile manifesto and introduce practices such as daily stand-up meetings, writing story-based requirements, targeting shorter development cycles and assigning a product owner. In addition, they will modify their traditional milestone-driven development to incorporate more planning and feedback loops to react to inevitable changes in project requirements.
These hybrid agile teams may also model user stories as tasks in a project plan (although they will measure progress in story points vs. task hours). They will work with resource managers to assign shared resources (such as DBAs) to tasks on their project. And they will report back
on progress to executives using standard project management metrics such as percent complete, scheduled finish date and project health.
There are lots of benefits to a hybrid agile methodology and many enterprise software development teams are adopting this approach. Adding agile practices over time is highly recommended so teams can absorb the changes while still delivering on their commitments. For these teams, we also think it’s the best way to get to some of the end goals of the agile movement: a focus on customer satisfaction, frequent software delivery, close co-operation between business people and developers, and creating an empowered culture with motivated individuals.
In my last post, I wrote about collecting data to provide information for decision-making. There is no question that data is where we begin, but facts are not enough. What we really need is information—a meaningful interpretation and presentation of the data that gives us insight into a condition or situation.
For example, when I manage a project, I collect data about task performance, such as “Task A” started on January 5 and finished on January 12, it took 27 hours of effort and we spent $3000 on travel. Interesting facts, but they really don’t tell me enough to evaluate the task’s performance, its impact on the project, or help me make decisions about the remaining work or cost.
It turns out that “Task A” was scheduled to complete on January 14, making it ahead of schedule. Unfortunately, it isn’t on the critical path, so there’s no impact to the project schedule. We had planned to use 25 hours to complete the work, but even though we were two hours over our plan for the task, we’ve been running significantly below our labor estimates on the work performed to date, and we’re already about halfway to completion. Now for the bad news: the total travel budget for the project is $5000 and we still have two more trips planned. What was supposed to be a one-day trip, costing $1000 for three team members, turned into a three-day trip, costing $3000 because the team got stranded in a Chicago blizzard.
So what makes the second paragraph more useful than the first? In general, the second paragraph tells a complete story that informs, highlights what’s important and clearly identifies the actions or decisions needed. If we further dissect that paragraph, we can see a few specific attributes that make it more meaningful and useful: content, context, contrast and consequence.
Content: In the first paragraph, we know the facts, but the second paragraph takes the time to combine the facts into a story. By adding a little more detail, or content, the reader has a better grasp of “the five W’s”: who, what, where, when and why. Our desire to be brief and direct often results in repeated question-answer cycles, leaving the decision-maker to ferret out the relevant and important information before taking an appropriate action, delaying the process.
Context: While the first paragraph describes the amount of money that was spent on travel, it does nothing to explain the circumstances or context behind the expenditure. By providing the information about the blizzard, the decision-maker better understands why the expenditure was high and in a better position to make an informed decision regarding future travel expenditures.
Contrast: In the first paragraph, we know what date the task finished, but in the second paragraph, we know that it finished late. By including data from the project plan, the second paragraph is able to compare what was supposed to happen with what actually happened. This provides the decision-maker with a much better sense of the problem and apply an appropriate decision.
Consequence: In addition to understanding that a variance exists, we also need to be clear about the impact or consequence of the difference. Sure, the first task took a couple more hours than we had originally planned, but in the overall scheme of things, it really doesn’t require action. The budget variance on the other hand is significant since it pretty much blows our travel budget out of the water.
Turning data into meaningful information to drive a decision isn’t rocket science, but it does require some thought. Next time you put together a report, ask yourself: does this tell the full story? If not, it’s probably just data.
In my next post, I’ll write about presentation in the context of decision-making, including some thoughts on dashboards.