My apologies for the somewhat contorted title for this blog article, I tried to think of other ways to describe this concept but this was the best I could come up with for now. If anyone would like to suggest an alternative title once they have read this blog feel free to make a suggestion I am always open to new ideas and the wisdom of others.
If you have read some of my previous blogs you will know that I have a penchant for financial information when it comes to projects, I won’t go over old ground suffice to say I think financial information aligned to a project is extremely important.
Projects invariably introduce change as well as suffer it. Good Change Management processes can seek to manage change in a consistent and disciplined fashion but you will be hard pressed to resist change to your project.
If changes occur it is likely that they will impact the cost and budget of the project, in most cases changes will add to rather than detract from the cost of delivering a project. The final cost of a project can end up being markedly different from the forecast cost when the project was first considered. How does this distortion occur? Would it be useful to know when significant cost changes arise?
Through the use of custom “Workflow Controlled” fields, project detail pages and Project Server Workflow it is possible to engineer an environment where we can discretely capture changes to the approved budget over the lifecycle of the project along with a commentary outlining the reasons for the change at the time and perhaps more importantly preserve crucial cost information as the project progresses through its lifecycle.
To illustrate these concepts I am going to assume a simple lifecycle model that comprises these simple phases, you can design whatever workflow phases you require to suit your project environment, processes and governance model.
It is also worth explaining “Workflow Controlled” fields in this context. Only Project level fields can be made “Workflow Controlled” – task and resource fields are not available to be subject to Project Server Workflow. A “Workflow Controlled” field can be made required but only at a specific point in the project lifecycle. If a field is marked as Workflow Controlled the option to make it required when defining it is automatically removed. A “Workflow Controlled” field can then be made “Read-Only” subsequent to it being invested with data through the definition of Project Server Workflow Stages.
The intent in this illustration is to capture approved changes to the project budget within each stage of the lifecycle model. The “Current Approved Budget” will be the “Original Budget” plus approved budget changes for the current Stage. When first contemplating this approach I thought it might result in a plethora of additional related fields to support the approach but after a bit of thought realised this would not be the case.
For expediencies sake I am going to use abbreviations as follows:
- S1-S5 to represent the 5 Stages of the Lifecycle Model.
- ABC – Approved Budget Change which will be a field for Stages 2-4, it is assumed there will be no budget changes in the close stage and that the Initiate Stage provides the “Original Budget”.
- OB for Original Budget
- CAB – Current Approved Budget
The “Current Approved Budget” value is a calculated value which in each Stage will use the same formula, this may seem a bit counter-intuitive but let me explain as we go.
For Stage 1 we capture the Original Budget.
On submission to Project Server Workflow the Original Budget will be available to subsequent Stages but in “Read-Only” mode.
For Stage 2 we have the Original Budget (Read-Only) and can update the S2-ABC (Stage 2 Approved Budget Change) field to record any approved changes to budget during Stage 2. The CAB field will show a figure derived from a calculation as follows (OB+S2-ABC+S3-ABC+S4-ABC).
At this point we only have values for the first two elements of this calculation, the others will “emerge” as the project advances through the project lifecycle. This approach eliminates my perceived requirement to have to create multiple new dedicated fields for each lifecycle stage of the project. The fact that values for some fields in the calculation have not been provided does not impact the calculation, the missing values are simply “0”.
As a result the CAB figure reflects the Original Budget plus Approved Budget Changes in Stage 2 plus two nil values. When appropriate the project can be subjected to Project Server Workflow and advanced to Stage 3. At this point both the Original Budget and the S2-ABC fields are marked as “Read-Only” preserving the Original Budget and Approved Budget Changes for Stage 2.
The S3-ABC field will now be available to edit, as a result the Current Approved Budget will now reflect two read-only values (OB and S2-ABC) plus any edits to the S3-ABC field plus one nil value for the remaining stage where Approved Budget Changes can be introduced. Again when appropriate the project can be subjected to Project Server Workflow and advanced to Stage 4. At this point both the Original Budget, S2-ABC and S3-ABC fields are marked as “Read-Only” preserving the Original Budget and Approved Budget Changes for Stages 2 & 3.
The S4-ABC field will now be available to edit, as a result the Current Approved Budget will now reflect three read-only values (OB, S2-ABC and S3-ABC) plus any edits to the S4-ABC field, the S4 Stage being the final stage where Approved Budget Changes can be introduced. Again when appropriate the project can be subjected to Project Server Workflow and advanced to Stage 5. At this point the Original Budget, S2-ABC, S3-ABC and S4-ABC fields are all marked as “Read-Only” preserving the Original Budget and Approved Budget Changes for Stages 2, 3 & 4.
By using this approach the Current Approved Budget figure will be an evolving “live” attribute of the project that uses both read-write and read-only values to give a current figure. The grid below illustrates how the information would emerge over the life cycle of a project.
This approach need not be restricted to just 5 project lifecycle stages as illustrated here. As part of good governance it would be useful to capture comments explaining the rationale behind the approved budget change during each lifecycle stage of the project, as with cost fields these multi line text fields could be made read-only once a project had been subjected to project workflow.
Given that we capture the approved budget change at each stage of the lifecycle the increase in cost is evident, the change in the overall cost of the project can be appreciated incrementally. This may provide an organisation with insight into where there may be problems and where there may be room for improvement. My illustration assumes just a single approved change for each stage of the life-cycle, for a more sophisticated governance model there may be multiple occasions where a change to the budget could arise, this would simply require more fields to be created to support this approach.
On a simplistic basis it would be reasonable to expect that changes to the budget would reduce as the project advances through the lifecycle. We should be moving towards certainty as a project progresses and as a result reducing the opportunity for change to the project to occur. If a higher approved change arose in a subsequent stage of the project than in previous stages it might suggest significant risk, major change or that the project was poorly considered during the initiation stage.
Graphically portraying this data in a form such as that shown below could also highlight problems, as the histogram bars increase in height each additional segment should be smaller than the previous one, if a subsequent segment is larger than its predecessor that could be an indication that there are problems.