Demand management

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 portfoliomanagement. Wecanalmosthear you from here: "Hold on a minute, Demand BoyI
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:"TrueDemandManagementisthefirst
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"inotherwords,itshouldbeeasyand clean to simply take a request for work and convert it into a
projecttheenterpriseshouldnothavetoradically 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 forgetsometimes,itmakessensetostopacurrentproject to make room for a "new" project. That
doesn't necessarily mean the current project was a mistakeitsimply 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, ClarityPPM.
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"ideasfornew 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 itemsbreakfix,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 distributiveyoudon'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"cannotbeconvertedinto
ataskonanexisting projectsayforexample,ataskonanaggregate,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" objectwhataboutit?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 / influencersrightdowntoterminatingthe
requestifnotprogressed 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 timeandtothink:theyallstartoutas"Incidents"theClarityplatform 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
Proposal
movesto
Executive
Review
InitialFiltering
thru
IdeaCouncil
ConceptStage
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 submission
No
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

Demand management

More Related Content

What's hot

Viewers also liked

Similar to Demand management

Demand management