The Business Driven PMO

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In my last post, I busted a common misperception that agile projects don’t provide enough executive visibility. Today I’m going after a second widely-perceived myth: Agile Projects Lack Reliable Scheduled Finish Dates.

It’s a fact that agile methods are designed to adapt quickly to changing realities, whereas more traditional methods focus on planning the future in detail. Although agile teams shy away from providing guaranteed delivery dates (given the cone of uncertainty around a project), it’s untrue that an agile project can’t provide a scheduled finish date.

Agile teams use ‘just-in-time’ estimation for iterations and focus on delivering business value incrementally. However release and roadmap planning is used for longer range estimates. If an executive hears that an agile team is only prepared to give estimated delivery dates for the next couple of iterations, it should raise a warning flag about the team’s capability to build a credible release plan.

The use of ‘epics’ (large stories) and ‘themes’ (groups of stories) can be used to estimate work that still requires detailed scoping. To be able to estimate with some degree of reliability, an agile team will need to have some degree of normalization around the size of stories and understand their velocity (story points delivered in an iteration).

Once the differences with agile projects are understood, developing a PPM framework with standard metrics that apply to both agile and traditional projects is important. Scheduled finish date is just one of the five common metrics that enable executives to get visibility into project status, regardless of the delivery method:

• Scheduled Finish Date. ‘Planned finish date’ is the estimate made at the inception of a project for the planned delivery date, whereas ‘scheduled finish date’ is the estimate of a project finish date at any given point in time based on current data. For a traditional project, this is based on the task plan and critical path for the project. For an agile project, it is based on the release plan. Given a ‘cone of uncertainty’ exists regardless of project methodology, the accuracy of scheduled finish dates should be comparable for both traditional and agile projects. Comparing scheduled finish date to planned finish date will give an indication of the team’s ability to estimate delivery dates accurately.

• Percent Complete. Percent complete provides an indication of project progress. Percent complete for a traditional project is calculated by summing the hours for completed tasks and dividing by the total task hours for a project. In contrast, an agile project progress is measured by story points delivered. Percent complete is calculated by story points accepted divided by total story points for a project.

• Scope Changes. Percent complete gives an indication of progress, but does not show if the scope is changing on a project. For traditional projects this is typically represented by the number of change requests. For an agile project, it is typically measured by the change in total story points over time.

• Actual Cost vs. Budget. Both traditional and agile projects have capital and operational expenses that are tracked. Actual cost vs. budgeted cost should be reported, regardless of the project methodology.

However, it’s not appropriate to ask an agile team to track time at a task level to calculate resource costs. Instead, resources should be dedicated to an agile team and costs calculated accordingly.

• Project Health. Project health is a summary metric that indicates if a project is ‘on track’, ‘needs attention’ or is ‘in trouble’, usually indicated by Green, Yellow, Red stoplight colors. This metric varies by organization and is often calculated using conditional logic based on the four metrics above, as well as other data such as outstanding issues. One of the simplest ways to calculate project health is to compare actual percent complete with the expected percent complete based on the start date and scheduled finish date (assuming the velocity of work delivery across the project timeframe is uniform). A project health status of ‘needs attention’ or ‘in trouble’ is often triggered when projects are not delivering business value, there are significant scope changes, costs exceed budget or there are major unresolved issues on the project.

Providing these metrics in a dashboard format using a PPM system enables executives to quickly identify projects that require focus or intervention, regardless of the project management methodology employed for its execution.

Do you agree? What’s worked for your organization and what’s fallen flat on its face? Let us know here. 

The agile movement has had a significant influence on best practices for project management.

However, some agile ideas about embracing change, ‘just-in-time’ planning, and eliminating hierarchical decision-making have led to misconceptions about the compatibility of agile projects with PPM processes. Over the next three posts I’ll set the record straight about common project management fallacies that have led to concerns over how to monitor and control an agile project as part of a project portfolio.

Let’s look at the first myth: Agile Projects Don’t Provide Enough Executive Visibility

A large part of the popularity of agile is the belief that teams should be empowered to make business decisions rather than relying on executive stakeholders for approval. Empowering a team, however, does not mean they shouldn’t provide timely executive status reporting. The struggle many agile teams face is the requirement to provide status reporting in a format that is inconsistent with agile practices. For example, a requirement that an agile team maintains a separate task plan to enable reporting on metrics such as ‘percent complete’ can negatively impact the benefits of an agile approach. Instead, executives need to learn how to interpret project status from an agile team rather than impose reporting requirements that are not consistent with agile.

Let’s take percent complete as an example, which provides an indication of project progress. Percent complete for a traditional projects is calculated by summing the actual hours for tasks and dividing by the total task hours for a project. In contrast, an agile project progress is measured by story points delivered. Percent complete is calculated by story points accepted divided by total story points for a project. Educating executives on what a story point is and how it measures progress enables agile teams to report progress in the unit that makes sense for their team.

One caveat is that reporting on ‘percent complete’ on a program when the underlying projects are using different units, such as task hours and story points, can lead to inconsistent results. In this case, finding a common metric across projects is advisable, such as ‘function points’ or ‘business value points’. This requires an organization with a high degree of PPM maturity, a well-defined methodology and strong training programs to educate program and project managers.

The rise of agile development practices is driving many benefits to organizations by creating a culture of continuous feedback and a focus on delivering high quality software that meets customer needs. Although some fallacies around agile development exist, it should not deter PMOs and executives from encouraging agile adoption in their organizations where appropriate. Project managers and PMOs should carefully consider which projects are suitable for agile methodologies. They should also develop a PPM framework that applies to both agile and traditional projects to enable executives to get visibility into project status, regardless of the delivery method.

What are your thoughts? Have you had experience educating executives on the differences between agile and traditional projects? Let me know.

Earlier this year, we polled more than 60 enterprises that have been using Daptiv to track some of the emerging trends in the industry.

Our survey asked about integration plans, budget levels, as well as corporate structure. We had customers from a wide variety of industries including financial services, healthcare and business services. Here are a few interesting results from the research:

1. Business PMOs are prevalent and reporting to the C-Suite

Back in November, we predicted that more enterprise project management offices (EPMOs) will report to the CIO as PPM best practices are taken out of IT and into the business units. Our survey results show that 33% of the respondents have their PMO or EPMO reporting directly to the CIO, with others reporting to C-Level executives including the COO (19%), CEO (11%) or CFO (8%). This indicates the emergence of the PMO as a vital role in shaping not just IT, but overall business strategy.

2. Integration is making PPM the linchpin of strategic decision making

Nearly half of the survey respondent said they have or are planning integration to enterprise systems like ERP, SAP, Oracle, etc. This enables users to gain better insight, management and control over business processes and provides a single view of project costs. Integrating PPM with IT operations tools and application development tools (including agile tools) is also becoming more common and allows enterprises to integrate real-time project data and support a variety of project management methodologies.

3. PMO budgets are increasing

In a potentially good sign of business investment, many Daptiv customers are seeing their budgets increasing in order to take on more projects. Out of all the Daptiv customers responding to the survey, 37% reported that their PMO budget would be increasing, some by as much as 20% or more. Only 6% of those surveyed reported that their budget would be decreasing in 2011.

Let us know what you think – is this consistent with what your organization is seeing?