White Paper

Demand Management:

Using CA Clarity PPM

to control the pipeline

Richard Shapiro,

Engagement Manager,

Digital Celerity, LLC

2

CONTENTS

Understanding the Pipeline .................................................................................................................................................................... 2

What Gets into the Queue and Why? ................................................................................................................................................ 4

Can’t Stop the Flood…………. ............................................................................................................................................................... 5

Demand Management Implementation ............................................................................................................................................ 8

A Beginning approach ...................................................................................................................................................................... 12

Using Clarity to estimate ideas ......................................................................................................................................................... 13

Using Demand Management to report the pipeline ........................................................................................................................ 15

Conclusions ...................................................................................................................................................................................... 16

UNDERSTANDING THE PIPELINE

Anyone close to organization governance and the constant tradeoffs between opportunities, projects and

limited resources understands that being able to clearly and proactively see the pipeline of work before it

becomes approved is not only a critical success factor of the overall Governance effort (choosing what actually

becomes approved, and then mapping consistently how the work will be executed), but also the success of the

organization in general. To this end, most organizations have chosen to adopt a proactive governance process

for two primary reasons:

1) Economic realities cause us to consistently do more with less; and

2) Constantly shifting priorities work against the successful completion of our current project commitments.

The more successful organizations are successful, in large measure, because they have developed ways to

3

monitor, prioritize and control the pipeline. They are consistently better at quantitatively (and qualitatively)

assessing the priority of incoming Ideas, and have used that control to maximize their use of limited

resources.

The pipeline consists principally of three work types:

1) Items that turn into full blown projects creating new products and/or services

2) Items that enhance and/or add to existing products and/or services

3) Items that may drive up support and maintenance efforts

These three work types can be broken down further:

1) Revenue Generating Ideas

2) Cost Avoidance Ideas

3) Products/Services which Grow the Business

4) Legal Mandates

5) New Support/Maintenance efforts

At either end of this spectrum, the decision model is pretty straightforward. Bad ideas are not good for the

business, not good investments on their own standing or by comparison, not connected at the core to the Value

Structure for the enterprise, or not contributing to the overall goals and revenue stream of the organization.

Required work shares the same simple decision model, as do the Operations / Break Fix variety of work, except

that they are at the other end of the Value Structure. They are good for the business to the degree that there is

no reason not to do them, they are good investments on their own regardless of the existence of other

supporting initiatives, they are directly connected to the goals and objectives of the Organization, or are

regulatory obligations that cannot be staged, postponed, or otherwise denied.

It is the middle of this spectrum where most "decisioning" work is required, sometimes in consideration of the

"Required” and the "Support and Maintenance" that simply have to be accommodated. That decision process can

loosely be considered the fundamental center of true Demand Management.

4

WHAT GETS INTO THE QUEUE AND WHY?

Consider for a moment that if your Organization is like most, this list of work-candidates largely is among the

following categories, or something similar to them:

1. Bad Ideas - Hopefully doesn't show up anywhere

2. Internal work – Investments in the future of the organization

3. Good Ideas – Revenue generators, cost avoiders, work that grows the business, etc.

4. Required – Internal or external mandates.

5. Support and Maintenance – Required to support the current product stream, comes from Help Desk or Support

tickets, and/or is generated by new products coming on line.

For the purposes of this discussion, we will abandon the "Bad Ideas" candidate group altogether for obvious

reasons.

5

CAN’T STOP THE FLOOD………….

The organization cannot restrict the amount of work that is requested of it. We can't say: "Please stop asking us to

build things / enhance things / fix things for you. We don't have the resources to do any more."

The battery of questions we ask ourselves shouldn't focus on whether we do more "work" in response to requests; it

should rather be:

1) Based upon current constraints (resources / skills), which work from "the flood" should we execute in

what order?

2) Based upon estimated easement of current constraints (more resources, current initiatives canceled, etc.)

which additional work could we take on to optimize the value of the portfolio?

Notice the reference to portfolio management. We can almost hear you from here: "Hold on a minute, Demand BoyI

thought we were talking about Demand Management, not Portfolio Management!" Well, we are, but if the process

of deciding the work that should be done (based upon established criteria) is a fundamental principle in true

Demand Management, then we’ll go ahead and step out on a limb and say: "True Demand Management is the first

stepping stone to true Portfolio Management, and therefore, the value and health of the portfolio is only as robust

as the mechanism by which the organization manages Demand.

The "Demand Management Maturity Model" as expressed below will more often than not describe predictively whether

or not the portfolio is approaching value optimization, and whether in fact it is as healthy as it could be. While

originally designed for IT departments, this model is valid for any other organization with a PMO:

6

You'll notice that the key differences from station to station as the organization moves along the scale are largely

based upon the level of proficiency with which the organization receives, qualifies or disqualifies, and prioritizes

requested work.

Included in the development of proficiency is the creation and broad (if not universal) adoption of a consistent and

controlled mechanism by which the work is requested.

There are several important characteristics that this mechanism must possess to truly be effective and successful on

an enterprise scale.

1. Request-making access to the mechanism must be controlled (rights-based access). Without this caveat in

place, any mechanism will tend to become a "suggestion box", or a repository for ideas, both good and bad.

Only "qualified" requestors should have access to this mechanism. This list may consist of representatives of the

organizations customers, but should never include all "customer" resources.

2. The mechanism must be scalable In cooperation with Condition 1 above: If your Demand

Management toolset cannot handle large volumes of incoming Ideas, it may soon be

overwhelmed by large numbers of small requests.

7

3. There should be appropriate traceability from cradle to grave - encompassing the entire lifecycle of the

"work candidate" it's conversion to an actual project, and the entire lifecycle of that resulting project.

4. The mechanism should allow for the composition of review parties, panels or councils - and would ideally be

the repository for any and all information necessary for the party, panel or council to render a go - no go

decision on any single request.

5. In driving the request thru the approval process (recommended based upon size, scope, potential return)

the mechanism SHOULD take advantage of current architecture, procedures and processes in "maturing"

the "work"in other words, it should be easy and clean to simply take a request for work and convert it into a

projectthe enterprise should not have to radically change its operating mechanisms to comply with the

mechanism, the mechanism should bend to the enterprise.

6. The mechanism should provide either an analysis platform by which the request-for-work can be prodded,

probed, dismantled and dissected, or it should accommodate the loading and storing of externally developed analysis

for cost / benefit research.

7. There should be a bona-fide connection between real enterprise financial information and the mechanism to

support the analysis above, such as a formal business case.

8. The mechanism should provide complete visibility into the existing portfolio as well as the queue of requested

work to appropriately compare work candidates against not only one another, but against initiatives already

underway. Let's not forgetsometimes, it makes sense to stop a current project to make room for a "new" project. That

doesn't necessarily mean the current project was a mistakeit simply means that something better has come along.

9. The mechanism should have a robust output and storage functionality to facilitate future decisions, as well as

to review with the client when they inevitably ask: "What have you done for me this year?"

10. To provide for a gated approval process (recommended based upon size, scope, potential return, etc.), the

mechanism should provide automation and workflow in progressing the request review lifecycle, with jumping off

points throughout. Self- containment, built in interfaces, or export functionalities are critical. Automation or the click of

a single button seems to make people the happiest.

8

DEMAND MANAGEMENT IMPLEMENTATION

A major Midwestern financial institution, which had made a commitment to better prioritizing their queue of work

candidates, elected to leverage a tool that already existed in their environment, Clarity PPM.

As a portion of their scheduled upgrade from previous versions, the organization elected to roll out a portion of the

Demand Management Module available in the out of the box configuration of Clarity to complement their pre-

existing Help Desk platform. Service tickets (incidents) and similar work would continue to be routed to their

service platform, and Clarity would be the application of record for the staging and marshalling of "Project-Type"

work candidates. What was unclear as they made their decision was how this Demand Management module would

be configured to accommodate their requirements.

Out of the box, Clarity is installed with two specific functionalities within the Demand Management

Module. The first is a mechanism to capture and catalogue "Ideas"ideas for new products, assets,

projects, etc., all of which can be directly (within the application) converted to a Project. The second is a

mechanism to capture "Incidents", which could be considered help desk related itemsbreak fix, desktop

assistance, etc. which would normally be routed via a true Customer Service / Help Desk platform.

By all accounts, the "Incidents" component of the Demand Management module in Clarity is not as robust as

many of the other utilities and apps that are available in the marketplace, and was never intended to be. In fact,

even the un-initiated will note that Computer Associates (the owner of the Clarity application) already has a highly

robust Service Management Solution in Unicenter, so it is clear that the "Incident" component of the Demand

Module in Clarity is a leftover design augmentation from the prior release documentation developed before CA

acquired Niku and hence Clarity. It's just sitting there, waiting to be leveraged.

However, a highly desirable and well thought out design characteristic that emerges from a closer inspection of

both the Idea "object" and the Incident "object", is that both are designed out of box to quickly and easily

become other objects when necessary. Think of it this way: Somebody in your organization comes up with a

good "Idea" for a project, or a service, or a product, or some other asset that creates value for the organization.

Suppose this person actually recorded their "Idea" in Clarity and sent it through the organization's review

process (whatever it may be). Further suppose that since the specs for the "Idea" are fully encapsulated within

a specific location, and can be exploded for review simply and easily, the review process becomes more virtual

and distributiveyou don't have to gather in the war room to discuss it amongst the decision makers /

influencers.

9

Finally, imagine that this good "Idea" really is a "good" Idea, and you want to put it in motion. Thanks to some well-

designed code, Clarity will allow you to left click on a button, and with the appropriate access rights, convert this

"Idea" into a project, product, asset, or "other" investment which will be stored within the Clarity database and

visible from other modules.

At first glance, this would appear to be a perfect candidate for a work request queuing mechanism. If I want to

request project work, all I have to do is submit an "Idea", right?

Well, yes, but what if the "idea" you've come up with isn't really big enough or unique enough to become its own full-

blown work plan? What if it looks more like a component (task, activity, or phase) of an existing work plan, say for

example, an annual operating work plan? Well, here's the rub with the Idea "object"Clarity "Ideas" cannot be converted into

a task on an existing projectsay for example, a task on an aggregate, annual operations or non-project development work

plan. Unfortunately, that single hitch will get in the way rather frequently in most organizations.

Ah, but the "Incident" objectwhat about it? Can "Incidents" be converted the same way into projects OR tasks? Happily,

the answer is "Yes, as slick as a Denver freeway in January". This little factoid, in concert with the fact that the

"Incident" object would have simply languished there on screen (and would never have been capitalized upon due

to Peregrine's presence on the property), led us to decide to leverage the "Incident" object in the creation of a true

"Work Request" object, which serves as the queue for all IT Project work. What's more, the "Incident" object has an

"Audit Trail" functionality, which allows visibility into major / minor events in the lifecycle of the object, as well as an

"Associations" view, which allows the user to see which (if any) projects or tasks the "Incident" has spawned. Lastly,

we leveraged the "Incident" object because not only can it give way to either a project or a task, but it can also be

converted multiple times, which accommodates the very real possibility within this organization that a single request

may be global enough to spawn several projects or tasks.

To begin, we have to ask the question: "What is a Project?"

Generally speaking, most organizations can qualify a request as a "Project Request" by the size of the effort, either in

dollars or in hours. This particular client didn't have an enterprise standard by which to answer this question already in

place, nor did they have any global "demand" tools at their universal disposal. Everybody went about it in a different

way, via a different mechanism, from spreadsheets to complex databases. So not only did we not have a universal

model from which to pattern our "Work Request" (instead we had broadly variant and divergent requirements), we

also didn't have processes, procedures, or business rules from which to build. Bring out the Requirements Analysts!

After several long weeks of eliciting and documenting requirements for the "Work Request", we were able

to arrive at the roles, processes and business rules by which the organization would live and to which the

application would bend. We set about the actual configuration of the app, and by the use of large-scale

JAD sessions and review panels, the first prototypes we turned over for review (consisting of re-labeled

attributes, custom fields, suppression of non-related attributes, and financials) morphed over the course of

10

90 days into what is today the enterprise standard for the request, analysis, and approval of IT Work.

The overview of the process is shown below:

Throughout the process, the requestor is merely the catalyst for the creation of the record in the database. We

designed our process in this fashion because within this particular organization, the folks who request the work are the

customers of IT, the business. Their requests are represented by a Demand Manager (rather than approved by one)

within this process, and it is the Demand Manager who becomes the champion for the request, shepherding it from

creation thru realization, and even into its next lifecycle as a Project or Task.

Hence, the Requestor has one view of the request itself, at its most generic and basic level, and all other roles

within the process have more robust and granular views of the Request.

Since Clarity does not provide any degree of field level security, this "separate views" requirement was tricky. By the

use of sub-objects and display conditions, we were able to create display scenarios in which the requestor enters the

11

high level details of the request (which can include attachments, etc.), but can never see any more of the request. In

this organization, the Requestor is locked out of the review process after having submitted the case for doing the

work. The Assessment Teams can see the Requestors' view as well as a second view of their own used for estimating

and analyzing hours, dollars and impact to the portfolio. The Approvers can see an additional third view for funding

information and approval signoffs, and finally the Demand Manager would see all of the above and be able to

augment them via his / her own sub-object (not seen by the Requestor) and portlet (also not seen by the Requestor).

Notice that the process shown above is gated. In this dramatic oversimplification, we've listed four gates. In actuality,

the Work Request Lifecycle within this organization consists of eleven different "states" that the request may lie in on

its way to ultimately being approved as a project or task, or being rejected. We leveraged the "Category" attribute to

list these states by adding the appropriate values to the "Browse Category" lookup, and suppressing the values that

already existed there. Between specific gates, almost surgical activities are prescribed, from high level analysis of

the request for general value and completeness, down to role-and- infrastructure-based building of detailed

estimates for the eventual work, which can then be leveraged in the decision making process.

To facilitate tracking and reporting, we applied Clarity workflow (process) to the object, created around the transition

from value to value in the "Browse Category" lookup. The workflow is complete with reminders, notifications, and

systems actions that will automatically or manually reposition the request status in the process flow based upon

events in its lifecycle and interventions by shepherds and decision makers / influencersright down to terminating the

request if not progressed from its current state (whatever that state is) within an appropriate period.

By the use of delivered Clarity data elements, a robust set of business rules, competent modeling and mentoring,

solid business processes, and some creative custom data elements and objects, the "Incident" in Clarity is now a

fully functional work requesting vehicle for a organization with 9000 potential requestors and upwards of 5000 IT

projects in flight at a timeand to think: they all start out as "Incidents"the Clarity platform has found yet another place

among the most versatile and effective applications in the enterprise project management marketplace.

12

A BEGINNING APPROACH

In another financial institution, we were able to accommodate the Idea workflow within Clarity without triggering much initial

development work within Clarity. The priority was to use existing Clarity functions and engage a governance process quickly, to be

refined over time. In this organization, it was important that the governance process of reviewing Ideas prior to review and approval

be strengthened quickly and that Clarity be used to track and document the Ideas as they flowed through the process. This initial

approach works best when the object of the Idea Life Cycle is to settle competing priorities for a limited resource pool.

As seen below, a three stage approach was used. First, each new Idea is classified as a Concept and a high-level description is

captured in Clarity, along with an initial scope, business case and estimation documents. When ready, it is submitted to an Idea

Council, which reviews the idea for possible approval.

In the Second tier, the Idea Council checks the documentation, returns it for further development if needed, and assigns a liaison

(Portfolio Manager) to take ownership of the development of the Idea. Not shown below, an Idea Council, in this approach, is given

the authority to approve small projects and/or enhancements to existing products, within certain limits.

Finally, for the remaining large projects, an Executive review takes place which makes the final decisions as to which work moves

forward and which do not.

Idea Life Cycle Overview

Pro

po

sa

l

mo

ve

s to

Exe

cu

tive

Re

vie

w

Initia

l F

ilte

rin

g

thru

Ide

a C

ou

ncil

Co

nce

pt S

tag

e

Business Unit

creates a

Concept

Start

Review Submitted

Idea to Idea

Council

Enter and

Classify

Idea

Schedule review

by the Executive

Review group

Clarity

More

Information

needed?

No

Yes

Initial Scope

definition and

identification of

Idea type

Hi Level

Business Case Submit Idea to the

Idea Council

Prepare

conceptual

description

Hi Level Cost

estimation

>20% confidence

Cross Unit

Impacts

Business Liaison refines

documentation with business for

formal submissionNo

Engage Business

Liaison

Executive Review

Board

decides

· Approve

· Reject

· Hold

· Further Study

Clarity

Clarity

13

USING CLARITY TO ESTIMATE IDEAS

A very common question when using Clarity to track Ideas is simply put: “Is it better to start the process in the Idea Object or start

later on in the Project Object?” Many organizations do not use Ideas, but simply start Projects for everything.

This is not generally considered good practice, insofar as co-mingling Ideas with Projects in the same Clarity object severely handicaps

reporting, portlet generation and automated workflow processes.

OUT OF THE BOX STATE:

The Clarity Idea object, as deployed out of the box, can contain resources in two ways:

1. Resources can be added to Ideas and if Time entry is enabled, they can post time to an Idea. This is done to capture the

costs of estimation and governance of a particular Idea. There are no changes needed to the Clarity system. This is current

functionality. The right to enable time entry has been moved to an Idea Administration page, and access to that page can be limited

as needed.

2. Resources and/or roles can be added to Ideas through the Team page, identical to the same page in a Project:

14

In the above illustration, we have added four roles and made Allocations against them.

In the below illustration, we have drilled into the Architect/Designer role, to see what else it is assigned to (development data):

Clarity provides this functionality so that an Idea owner can see when resources might be available in the event that this idea is

converted to a project.

There is a natural tendency to begin the estimation process right here. By adding roles, and by working in possible ETCs and/or

Allocations, the Idea manager is beginning his high level estimate of the Idea. When properly done, he will use this data to construct

his desired schedule. If he does not, his desired schedule is performed in a vacuum, and will inevitably need to be changed.

However, Clarity does not provide the retention of this data when/if the Idea is converted to a Project. After conversion, the Idea

must be repopulated with the Resources and/or Roles needed in order to see the availability.

BEST PRACTICE:

One of the principle benefits of Clarity Ideation is the understanding of Idea needs on the Resource pool and using that information to

properly schedule and fund work. When an Idea is generating resource contention (the large majority will), there are several options

which should be presented to the governing body. These options are part of the process and those responsible need to develop

these as part of the decision making process:

1. Scheduling scenarios: (Some specific) Resources are not available now, but will be available on X dates, so we can start the

project then without having to hire additional resources.

15

2. Prioritization scenarios: This project needs to be completed on a fixed date and resource contention is an issue. It is caused by

XYZ specific projects. If those projects are shifted (delayed, expedited, etc.) we can do this project without having to hire additional

resources.

3. New Needs scenarios: We need to do this project by a fixed date, but resources are not available due to XYZ, so we absolutely

need to bring in additional resources.

Options:

1. Use the current Clarity out of the box functionality, and control this through Idea Approval. This carries with it the loss of the

Resource data when the Idea is converted.

Pro:

· Costs nothing.

Con:

· Discourages thorough use of the Resource Planning capability of the system as the Idea owners realize that they will have to repeat the exercise in the Project.

2. Enhance Clarity to be capable of bringing over the resource data as the Idea is converted.

Pros:

· Encourages use of the feature.

· Brings a better understanding of the impacts of the idea on the resource pool.

Con:

· Costs approximately 40 - 60 hours of custom technical resource consulting and at least 16

hours of test time.

USING DEMAND MANAGEMENT TO REPORT THE PIPELINE

One of the most powerful features of Clarity is its ability to produce useful data for Reports and Portlets. The Pipeline of work,

including Ideas, is an excellent example of how this can work.

A wide variety of reports can be created to help the organization see and better understand what is coming, what is proposed, and

what the impacts of each item in the Pipeline might be.

In this example, we can see the list of Ideas which is scheduled for the next few months; we can see preset stoplight indicators to help

us to immediately identify key metrics, and we can read details and notes about each Idea.

When done as a Portlet, this type of data can easily be drilled into, so that the details of each Idea are readily visible to the user,

provided of course that proper security rights have been granted. Portlets have the advantage of presenting real time data.

16

When done as a Report, this type of data can readily be shared in emails, on Intranet websites, etc., even without a Clarity account, so

that reviews and decisions can all be done from a common point of information.

CONCLUSIONS

Clarity PPM presents an opportunity to gain a full understanding of the demand for resources in ways in which other tools can not:

All data is from a Single Point of Truth – it is easily referenced and reportable.

All Ideas can be viewed in context with existing Demand – enabling end-to-end Resource Management

Governance is documented and facilitated – with standardized metrics and requirements

Transparency is guaranteed – within security guidelines, nothing is hidden from view

Workflow can be automated and audited – using existing Clarity functionality

Impacts can be understood – on Resources, other Projects and on Portfolios