CUMULATIVE FLOW DIAGRAMS
Portfolio
Status Reporting
One of my first
priorities at Ameriquest was to assess our portfolio of activities. After eight
months we can still only account for about 85% of the work. There was
resistance.
1. Some did not
understand we need information so management can verify our priorities.
2. Some know
that managements' priorities do not always align with their preferences.
Once we
overcame the initial resistance the next problem was to find an efficient way
to organize the data. I began by embedding a list in our weekly status report.
I collected all the data and I typed all the updates.
As we
penetrated deeper into the organization the volume of data increased. We soon needed
a mechanism to allow multiple people to make simultaneous updates. We got by for
a while by passing an Excel spreadsheet around in a sequence. Each project
manager had the spreadsheet for about 30-minutes and then passed it to the
next. We could get seven updates in four hours but the system broke down when
someone missed their turn.
Later we
migrated to a SQL Server database with a PHP front-end. Switching to a database
meant all the project managers can make updates simultaneously. Improving on
the tool allowed us to update our process. Our reporting process now had a work
flow.
·
Once
a week each project manager meets with their project sponsors and reviews their
portfolio.
·
At
least once a week each project manager gets status from their resources.
·
By
noon on Wednesday each project manger updates their portfolio and gives me a
briefing.
·
Every
Wednesday the resource managers send bullet points listing accomplishments for
the week.
·
Every
Wednesday I prepare a report on the portfolio and bullet points and then brief
my VP.
·
Every
Thursday my VP briefs the executive CIO.
DISCUSSION: Do you have a process for reporting on your portfolio?
Portfolio
Components
The PMI guide
on portfolio management focuses on programs and projects. As our process
matured we discovered other "stuff". For example, we do operational
work. Our system administrators log 150 to 200 hours per month. At least 80% of
that time is spent doing their "operational" work -- things that are
not unique and not temporary. Typical operational activities include reviewing
log files, checking space on disk drives, running batch jobs, etc. We can
capture this time in our time keeping system, but we are still unsure how to
show this in our portfolio.
We also use
project managers as the interface point to support projects external to our
organization. Our project manager acts as a communications specialists to
facilitate the execution of some else's project. It is important that we not
call this a project in our portfolio. Projects have SOX documentation
requirements and we are not the owners of those documents. We document this
type of service through a portfolio component we call an "engagement".
By our rules, an engagement is a project driven externally, it requires one of
our project managers to assist but we are not responsible for the project
documentation.
Somewhere
between daily operations and projects we have four types of miniature change
efforts we call "improvement initiatives".
·
We
are gradually tweaking the organization to be ITIL compatible. We support that
effort by assigning key people to specific ITIL roles. They then search for
opportunities to nudge the organization closer to the ITIL model. These efforts
rely on chaos to create opportunities where the participants are receptive to
change. Hence we cannot time line these efforts.
·
ITIL
also defines a process called a "Service Improvement Program" (SIP).
A typically SIP lasts about a dozen hours. For example, we executed a
"project" to add new reports onto our web portal. Later we found a
better way to display that data. The project was over. This new effort was too
small to warrant a project charter, requirements document, project plan,
project schedule, design specification, test plan, deployment plan and a
training plan. So we used a SIP. SIPs are miniature proactive improvement
projects.
·
When
the work is reactive instead of proactive we use the Root Cause Analysis (RCA)
process. We use an RCA when something bad happened and we need to know how to
fix it. The research typically only takes a few hours. The remediation might
take ten or twenty hours. Again, the effort is too small to warrant the burden
of a full set of project documents.
·
We
also have a continual effort to fill the gaps in our documentation. This is not
formalized as a project because the work is sporadic. Recently executive
management requested an update to the documents we give our business partners
when they want to rent disk space from us. The update took a couple days. We
account for those types of updates by listing our inventory of documents in the
portfolio and then flagging which are productionized and which are currently
under revision.
The list of
portfolio components now in use is shown below.
|
Program |
A grouping of
projects. |
|
Project |
Requires a
project manager, a signed charter and a project schedule. Also, projects over
160-hours in duration must comply with the PMO documentation requirements. |
|
Engagement |
Efforts
acting as a resource on a project driven by an external organization. |
|
Role |
A
responsibility to seek and champion improvements to bring us closer to
alignment with either ITIL or PMI. |
|
SIP |
A proactive
miniature project not to exceed 40-hours in duration. |
|
RCA |
A reactive
miniature project not to exceed 40-hours in duration. |
|
Documentation |
Policies
define the rules. Procedures document how-to. Templates are the forms to
request a service. And training materials include presentations and how-to
guides. |
DISCUSSION: What types of work do you list in your portfolio?
Portfolio
Reporting
It was because
so much of our work is sporadic and bundled in such miniature packages that we
needed a better way to report progress. Ideally we want an earned-value
assessment on unplanned activity. The method that works for us today is
Cumulative Flow Diagrams (CFD). David Anderson has an article posted on the
internet called "Using Cumulative Flow Diagrams"
(http://bdn.borland.com/article/0,1410,32410,00.html). David Anderson also describes
this technique in his book Agile
Management for Software Engineering
(ISBN 0-13-142460-2).
The way we
implemented CFD is simplistic. We took each type of portfolio component and
gave it a weight. Updating a policy, for example, has a weight of 0.1 --
meaning we expect one project manager to spend 10% of one week making the
update. Projects have a weight of 0.7 -- meaning the project manager is
expected to spend about 28 hours per week running the project. Like I said, this
is a very simplistic approach so do not focus on the values.
What we want is
trend analysis and the CFD gives us a simple diagram. A CFD shows three trend
lines in one graph. The first line shows the volume of work that has arrived.
The second line shows the volume of work that is underway. The third trend line
shows the volume of work that has been completed. In Excel this is a simple
area graph based on three columns.
This graph
quickly tells us if work is being completed in a timely manner or if we are
thrashing with lots of effort but no closure. In the illustration (below), for
example, the overall trend on the top line is rising at a faster rate than is
the third line. This is most pronounced in the interval between weeks 15 and
23. Work was accumulating and something had to be done to address the
situation. The three lines must be
parallel for the system to be in balance. To correct the situation, we either
needed to prune off some of the backlog or get more work completed. The CFD
allowed us to see the problem within two reporting cycles. It took six more
weeks to bring the situation under control, but without the CFD we could have
gone much longer without realizing the impending crises.
The CFD is also
predictive. A single "project" will enter the system in the area
representing pending work, cross the system as work in progress and exit the
system when completed. Thus, the slope of the lines indicates the speed at
which work is completed. With nice steep lines, the CFD for one activity might
look like the diagram shown below. One activity crosses the system horizontally
spending time in each of the three queues.
|
As I
mentioned earlier, the technique is very simple. We tally up the number of
pending, working and completed activities for each type of component in our
portfolio. I key those numbers into an Excel spreadsheet and multiply each by
the weight we assigned to that type of component. |
|
|
|
Next, I sum
the totals for the week, and display the results on the diagram. You see the
results graphically as well as numerically. For example, the table to the
right shows a steady increase in the amount of work that is pending. This
requires corrective action. On the other hand, the amount of on-going work is
steady. Steady is good because it is predictable and thus it can be improved. |
|
|
DISCUSSION: Does the concept
of CFD make sense?