A Simple Archive Workflow Example

It’s a workflow kind of month, and I figured I’d post this quick article on how to leverage UMT’s Project Essentials 2012 with Project Server 2010 to generate a no-code archive process.

In this case, the goal is to close the project out, and then create a report that will notify the administrator to archive the project at a later date.  Now, exactly what that archive process looks like is kind of up to you, as I find many organizations vary widely on definitions of the archive process and when they decide to trigger it.

First, I see up a couple of stages to move the project between.

image

Then I create a security group containing the folks who are required to archive a project.

image

Now we go into Project Essentials and generate a simple workflow.  I won’t walk you through step by step, but it’s pretty self explanatory once you open up the wizard.

image

The only real nuance is that I am adding a manual submittal requirement and an approval step for the Closing step.  This will require the PM to submit the project to be archived, and will send a notification to the members of the Custom Archive Approvers group to do so.

image

I link the workflow back to a project type, and run a project through the process.

image

When I get to Closing, I require the PM to manually approve it – or perhaps require the PMO to submit it.  That kicks off a workflow request that gets logged in the Workflow Task List.

image

One more step and we’re there.  Let’s create a new view of the Workflow Task List and modify it to filter only on those tasks exiting Closing and entering Archived.

image

I now have a screen which time stamps the date the project was closed, and gives the administrator an overview of which projects need to be archived.  As a project typically hangs around for 6-12 months before being archived, the administrator can review this list on a quarterly basis to identify candidates for the archive process.

image

Even better, add a simple workflow to the Workflow Task List to send an e-mail to the administrator 6 months after the workflow task has been created.

A Simple Archive Workflow Example

Project Management Systems vs. Accounting Systems

As many of you are aware, UMT has long been in the project financial governance space, and for the last several years has been proud to offer a tool that brings financial governance into the project portfolio management fold.

Often, when working with clients in designing their project financial governance processes, the question arises of how such a system would interact with an existing Line of Business (LOB) application such as SAP or PeopleSoft.  The LOB application is the official enterprise system of record and, as such, must contain the latest and greatest financial figures.

So what purpose can be served by effectively taking those figures and copying them to a secondary data repository?  As any enterprise architect would tell you, unless doing so enables a specific strategic capability, data should never be replicated into a secondary repository.

First off, let’s look at simple reporting.  One common scenario is for project managers to desire to capture accounting data in the same interface as project data.  For this purpose, creating a second data repository actually defeats the point, as we want for PMs to have access to the latest and greatest financial data.  In this scenario, we may be better served leveraging the rich SharePoint Business Intelligence features to surface accounting data through the use of Excel Services, SSRS, or PerformancePoint.

But what happens when we move beyond simple reporting?  Let’s take a look at a couple of scenarios that are enabled by the Project Essentials tool:

Preliminary Estimate Development – Often, as projects are developed, an initial business case is developed.  This financial business case may be captured in a project request form, a request database, an estimating tool, and occasionally within the PMIS.  Rarely is this sort of data captured in an information system that allows roll up and analysis.  Even rarer would be when this sort of data is captured within a LOB accounting application.

The general workflow we’ve seen is for the initial estimate to be prepared outside of the accounting application and then imported into the application upon project approval and funding (which then allows the organization to utilize portfolio analysis and optimization techniques).

Status Reporting – Nothing indicates the difference between project management and accounting more than status reporting.  This really hits to the heart of what Eric Uyttewaal once claimed in his book on project modeling, “The difference between accounting and project management is that accountants are focused on the past while project managers are focused on the future.”

Common scenarios in status reporting include the fact that the accounting application typically doesn’t display actual costs until the invoices for the work have been received.  This might happen anywhere from 30 to 90 days after the date of the actual work.  From a status reporting perspective, the project manager is better served depicting an unofficial “incurred” cost in the status report for work performed that has not yet been invoiced.

While this may violate basic accounting best practices, the reality is that this practice enables more effective status reporting and emphasizes the difference between the world of accounting and the world of project management.

Benefits Management – Another key aspect of project portfolio management lies in defining project financial benefits.  The general model involves defining timephased financial benefits before approving the project.  Upon project closeout, or at a predetermined period thereafter, those same benefits will be reviewed to assess whether or not the project was successful.

Since benefits are very often hypothetical values, they often have no place within the data structure of an accounting system.  Hence, benefits tracking is often relegated to the PMIS.

Integration with Project Management Workflow – It’s a lot easier to integrate with your project management workflow when you can replicate at least some of your accounting data into a PMIS. For example, imagine that you would want to take a snapshot of all of your actuals as well as project cost forecasts at each stage gate approval. This would allow you as an organization to assess how much you’ve spent within each stage gate, and what the forecast looks like upon the conclusion of each phase.

While a LOB accounting system will allow you to roll back time to identify the value of specific elements at any given period, it is often difficult to map those periods to the phase gates approvals in a true project management solution.  How could you determine how much you’d spent at the end of the Build stage from your LOB application without first looking up the date that you exited Build in your PMIS, and then cross referencing that with your LOB estimates?

Performance Management – And last but not least, what about financial requirements for performance management?  Often times, the project performance must be measured against various baselines.  For example, we may have a data structure within our accounting system to capture approved annual planning budget.  We may also have a structure to capture our current project forecast.  If a project has been approved out of cycle however, the annual planning figures will be zero.  We need to capture a snapshot of the forecasted cost at the time the project is approved to ensure that we are tracking against the appropriate financial baseline.

Looking for something a bit more substantial on the topic?  Check out UMT Chairman Mike Gruia’s white paper on the need for project financial governance.

Project Management Systems vs. Accounting Systems

From Strategic Outcome Management to Management of Outcomes

Another post in my process of digesting the outcomes of the recent PMO Symposium held in early November in Orlando…  As a result of attending this conference, I’ve been spending some time of late thinking about the nature of “strategy” and how PMOs and EPM tool sets fit into that.

My first thought of course, was to dig up an old book that’s been sitting on my shelf, an oldie but a goodie that I’ve tried to work through in the past, but never successfully.  This time, it was a lot more relevant – and a bit easier to work through.  If you’re looking to skim a rock over the surface of strategic thinking, there are probably worse places to start than Strategy Safari by Mintzberg, Lampel, and Ahlstrand.

Of course, I am still somewhat confused as to what the term “strategy” actually means, but my general conclusion after reading that book is “it depends,” which needless to say, is an answer that has always resonated with me.  Essentially, strategy boils down to a vision of the future along with the associated steps that are identified to achieve this future.  Now what that particular vision consists of or how it is defined?  That is another question…and a topic for another couple of blog posts.

(An old mentor of mine, might claim then that the strategy is the crystallization of our values, which when applied to the present world, allow us to identify a desired future state – but I digress.)

The book posits a number of different schools of strategic though, ranging from the centrally directed Planning School to the more emergent practices of the Learning School – both approaches to strategic thinking that I have seen in the client organizations I have worked within. 

An EPM tool could potentially support each (or at least some) of those schools in different ways.  For instance in the Planning School, we could take a top down capital budgeting approach to portfolio management, while in the Learning School, we could leverage a tool to identify constraints and therefore identify where the organization is actually heading.

Regardless of which school we subscribe to, let’s say, hypothetically, that we can define this desired future.  Not only can we define this desired future, but as an organization we can come to some sort of consensus as to what this future looks like.  Once we’ve done that, it’s but a short step to defining a set of characteristics that define initiatives that will get us one step closer to that desired future.

Those characteristics might look something like this…

image

And maybe, just maybe, we can come to a common agreement as to the relative ranking of those priorities.  That ranking may look like this….

image

Now here I should throw out a caveat that there is no software package that will manage your project portfolio.  There are however software packages that help you identify your priorities and assist you in calculating what the optimum portfolio may be in specific circumstances.  This is an example of that.

So once we have our desired outcomes defined, and our projects mapped to those desired outcomes, how do we assess how well we achieve those outcomes?  To quote this post I wrote before, how do we move from ensuring that we’re building the right thing to ensuring that we’re building the thing right?

Enter benefits realization, one of the (many) missing links in project management, and probably one of the leading justifications for the implementation of a PMO – insofar as project managers have traditionally been unsuited to the challenge of returning to a project 6 months to a year after completion to assess whether or not the project achieved the predicted ROI.

We can estimate our benefits over time as part of the business case…

image

….and then come back later and assess how well we met our targets:

image

So here what we’ve done is move down several layers of the V Model I wrote about in this post.  We’ve moved from the level of tracking project alignment to desired strategic outcomes to the level of managing our project outcome.

From Strategic Outcome Management to Management of Outcomes

The Importance of Cost Abstraction (Part II)

image_thumb1

In that last post, I talked about what cost abstraction is and claimed that it’s been going on in project management since times immemorial.  In this post, I’d like to take a look at why we practice cost abstraction, and what happens when we try to skip it.

First off, why do we practice abstraction in budgeting?  As I see it, there are three main reasons to do so (and no, if you’re reading this soon after I posted it, that’s not a set up for a Rick Perry joke…although yes, it could be with very little effort.)

  1. Abstraction and top down cost decomposition establishes the granularity of control over the portfolio with which the organization will assert itself.  The project manager generally has the authority to manage the project and to maintain acceptable variances within the specific limits set by the overall budget as perhaps enshrined within each of the cost codes.  Exceed those limits, and the organization must implement a Management of Change process as set out in the cost management plan.
  2. Abstraction sets up a crude form of stochastic modeling.  In this day and age, where many organizations have not matured to the level of performing true stochastic modeling to identify target cost ranges, the budget provides an upper limit on how much may be spent in a specific category – while still allowing the project manager the ability to manage controlled fluctuations in project cost.  In essence, this allows us to manage financial change at the appropriate level.
  3. Abstraction allows for complexity.  Where the overall organization may manage at the reduced complexity defined within a budget, the project manager may develop a much more complex cost model more appropriate to the needs of the project manager and the project controls team.  It is this more complex cost model that allows the team to develop and deliver against an effective Performance Management Baseline (PMB).

So that’s the “why.”  What happens if we ignore abstraction and attempt to implement our projects using only a top down budget?

Mechanically, things get difficult.

First off, managing the schedule gets problematic when we conflate the concept of “budget” and “estimate.” 

  • If we don’t allow the project manager to decompose each budgeted cost code any further in the schedule, then we are stuck managing performance at the level of the cost code.  Each of those cost codes would then have to be integrated with the schedule.  If the cost code is not so granular, then the lowest level intersection of the schedule and the cost code may be at too high of a level to support adequate performance monitoring.  Variance may have to be tracked at the phase level of the project but not at the task level.
  • The question of when a task gets closed out becomes muddied.  Consider the following scenario, a specific cost code is budgeted at $20,000.  Upon completion, we find that we spent $15,000 on the activity.  In Microsoft Project, the solution to this is quite easy, we set the task at 100% complete and then set Actual Cost to $15,000.  That will change our Cost field to $15,000.  Now what do we do with the remaining $5,000 in the budget?  Leave it for potential future risks that may dip into the same bucket?  Close it out and roll it back into the overall project contingency?  If we’re using our estimates to track budget, where do I track that $5,000?

Now I know what you’re thinking.  We could have just saved a baseline in all of that and used the baseline to represent the budget….which leads us to my next point….

  • A budget makes a poor excuse as the base for a performance management baseline.  In the above example, I may have budgeted $20,000 and spent $15,000, but perhaps I estimated $14,000 – assuming that the $20,000 harbored sufficient contingency to cover any potential issues.  If I take my budget as my performance management baseline, I would see my task as having a significant cost surplus.  Hooray for me, it looks like the entire project will come in under budget.  If I look at the estimate of $14,000 as my baseline, then I see that I actually came in marginally over expectations.

Given the granularity to which the budget is typically decomposed, that may not allow me as a project manager to identify enough control points within my project schedule to identify variances.  The aggregation and the potential inclusion of contingency within the PMB negate my ability to effectively manage the project costs.

It’s that layer of abstraction between the top down and the bottom up that makes the entire system work.

The Importance of Cost Abstraction (Part II)

The Importance of Cost Abstraction (Part I)

image

Since time immemorial, projects have been estimated with a combination of top down and bottom up practices.  That’s just how things are and have always been.  And when people try to circumvent those processes, bad things are likely to occur.

Specifically, what am I yammering about here?  Well let’s take a look at the project budgeting cycle.  Essentially, the way it typically works in a portfolio driven organization is that a budget for the project is developed as part of the approval cycle.  That budget may be decomposed into a level of granularity that is appropriate to the organization – generally driven by the level of expertise available or the level of volatility in project scope.  (And voila!  The organization has an illusion of control.)

Generally speaking though, that budget is tied to concepts, i.e. specific materials, labor types, or cost allocation codes that will be required to complete the project, but not yet tied to specific tasks with dates and calendars and such.  In other words, we have a flat estimate of the project costs with costs broken down into a specific granularity, but we have not yet tied that estimate to a timephased spending plan.

Now that we have a budget with specific funds allocated to each of the specific elements, we hand the project over to our scheduler.  The scheduler will develop the tasks of the schedule from the ground up, allocating specific cost elements such as construction contracts, specific components, or resources to the tasks.

Those tasks then roll up to a higher level, the level at which they may be mapped to the budget, i.e. a layer of abstraction that marries the top down budget to the bottom up estimate.

That layer of abstraction may occur in the Project client with Budget resources….

image

…or at the server level with a product such as our Project Essentials which allows you to define budget templates and then to map the bottom up estimates from the project plan to the predefined organizational template.

image

Great.  So that’s how things should work based on commonly accepted project management practices.  As I alluded to above, what happens if that mapping doesn’t happen as part of the project planning process?  

That will be the topic of my next post….

The Importance of Cost Abstraction (Part I)

Project Financial Server Post-SP1 Hotfix Released

Figured this was as good an opportunity as any to dip my blogging toe into the Project Financial Server (PFS) waters…

For those of you who are not familiar with PFS, it is a third party product that augments Project Server with a host of sophisticated financial management capabilities.  PFS is brought to you by UMT, who just happen to be not only the fine folks I work with but also the folks who brought you Project Portfolio Server before it was acquired by Microsoft and merged into Project Server.

For more information about PFS: http://www.projectfinancialserver.com/

For the text of the announcement regarding the hotfix, please see the UMT Software Development blog: http://www.ro.umt.com/blog/2011/03/20/umt-project-financial-server-sp1-cu1/

Project Financial Server Post-SP1 Hotfix Released