Quantified Objectives: A Fundamental Advance in Managing Software Development Projects - Page 4

Stuart James Woodward, DoubleHelix Software & Services Limited, http://www.doublehelix.co.uk/

The Specification of Resource Requirements

Resources are always limited. We are all concerned about the limited time, money, manpower and other resources we have available to our projects. Usually these are specified at the outset of a project or each of its phases. Resources are ‘used up’ at varying rates during the course of a project. They are, therefore, scalar in nature and should be specified as such, in a way similar to performance requirements. When planning a project, we must specify how much of the resources we plan to use to in order to meet the performance requirements.

For the sake of this discussion we shall assume that the only resources of interest are Project Duration and the Manpower Cost. In general, resource specification would take into account everything that requires to be paid for in order to execute the project.

Here are the proposed resource requirement specifications:

Project Duration Gist: The step-wise development or enhancement of functions needs to be balanced over the expected calendar period of the project to prove that value is being delivered to stakeholders. No assumption is made here of how this is done so an overall expected duration is allocated. Scale: Number of days. Meter: Project records. Survival [Final Deadline]: 360 "Project must not exceed one calendar year [rounded to 30 days per month]". Budget [To meet all specified Functional and Performance Requirements]: 300 "Project is allocated ten calendar months [rounded to 30 days per month]" ß Estimated requirement from CRM Project Plan [December 2002].

 

Manpower Cost Gist: Five available personnel will be allocated for the lifetime of this project at an average cost of <X>. The cost of manpower therefore equates to the number of days worked on the project by those personnel. Scale: Number of man-days. Meter: Project records. Survival [Final Deadline]: 1000 "Project must not exceed the total number of allocated man-days [limited to 200 days per person per calendar year pro-rata]". Budget: 750 "Project allocation [limited to 200 days per person per calendar year pro-rata]" ß Estimated requirement from CRM Project Plan [December 2002].

The Resource Target, the resource specification’s equivalent to a performance target, is in the form of the Budget parameter. This represents a level of the resource within which the project will commit to staying. Again, there are other possible parameters but they are not needed for the purposes of this paper.

In reality, projects often overrun on time and cost (an aspect of the Software Crisis described in numerous articles). Therefore, to avoid the organisation itself having to commit to an endless project, these resource requirements each accommodate a constraint in the form of the Survival parameter. In this case it specifies the longest duration and highest cost in man-days acceptable for the project. Beyond these, and in the absence of a further commitment of resources, the project would be stopped (because there are simply no more resources available to commit).

There are no Benchmarks here but they could be stated as useful comparisons with previous projects.

From these specifications it can be seen that to test and report the degree to which the resources are used up is straightforward. For example, if solution A takes 75 days to implement then it has consumed 25% of the budgeted Project Duration. If solution A also costs 150 man-days of effort then it has consumed 20% of the budgeted Manpower Cost.

Planning and Monitoring the Project

One of the key tasks in planning a software development project is to determine the schedule or sequence of implementation. Once the project is underway, monitoring determines the degree to which the performance requirements have been met. Evolutionary Project Management then allows re-planning at any appropriate point in the project.

Planning The Sequence of Implementation

A key characteristic of Evolutionary Project Management is that it enables the project manager to re-plan at the beginning of every step in order to maximise the Return on Investment (ROI) to stakeholders. The highest ROI is determined by calculating the ratio of performance to cost for each proposed design. In terms of the requirements, this is the ratio of the increase in performance levels to the resources used in realising those performance level increases. We must seek to implement those designs with the highest ratios of performance to cost first, thus maximising the ROI at each development step. This then will determine the sequence of implementation. To do this we must sum the estimated performance level increases or Performance Impacts and separately sum the estimated resource utilisations for each design.

Owing to the fact that, in general, each Performance Requirement will be specified using different scales of measure, we cannot simply add up the estimated impacts on those scales (you cannot add apples to oranges and expect to get a useful answer!). However, by ‘normalising‘ the estimated impacts as Percentage Impacts we can then add them together. A percentage impact is expressed as a percentage of the required performance level increase. We arrive at a total percentage impact on the system for the implementation of each design. We then do the same for the resource requirements. Then we are able to calculate the performance to cost ratio for each design and determine which one is estimated to provide the highest ROI. This result is established by using a Planguage device called an Impact Estimation Table.

Impact Estimation (IE)

Proposed Design Ideas à	Sum of Estimates	CAP Foundation	Upgraded Data Model	API	Risk Monitoring	CAP Groups	Counterparty Hierarchies
PERFORMANCE REQUIREMENTS
Credit Information Response 60 mins. <-> 2 mins. [2003]	105%	15%	30%		25%		35%
Credit Request Cycle 60 hours <-> 48 hours [2003]	95%	40%	15%	25%	15%
Credit Request Capacity 5 <-> 100 [2003]	85%	40%	5%	25%		15%
RESOURCE REQUIREMENTS
Project Duration 0 <-> 300	86%	12%	10%	8%	16%	10%	30%
Manpower Cost 0 <-> 750	77%	10%	12%	15%	5%	10%	25%
OVERALL IMPACT
Total Performance Level Increase	285%	95%	50%	50%	40%	15%	35%
Total Cost	163%	22%	22%	23%	21%	20%	55%
PERFORMANCE / COST RATIO		4.32	2.27	2.17	1.90	0.75	0.64

In the table above the performance and resource requirements are listed vertically down the left hand side. With each is specified a Baseline<->Target pair, the chosen benchmark and performance or resource target as appropriate, against which the percentage impact figures are estimated.

Along the horizontal axis at the top are the proposed design ideas to be implemented. A percentage impact figure is entered for each design against each requirement. Empty table cells mean that there is 0% impact e.g. it is estimated that the implementation of the API will have zero impact on the Credit Information Response performance requirement. Please note that the figures in the table are for demonstration purposes only.

The bottom line lists the performance to cost ratios for each design. I have deliberately listed the designs in order of decreasing performance to cost ratio to demonstrate the point that this determines the sequence of implementation.

As with other Planguage concepts in this paper, there are many other points that are not directly relevant to the argument being made. For example, this sequence will also have other dependencies such as the availability of resources at specific times. This is not factored into the IE table whose purpose here is to give a relative assessment of ROI.

Simultaneous Management of All Requirements

It is perfectly possible that a specific design could have a negative impact on one or more requirements. For example a design might compromise one requirement in favour of others. It is the total impact on all the requirements that is important in determining the performance to cost. We must seek to manage all the key requirements otherwise it is inevitable that one or more will be disregarded or considered only subjectively during project planning. The IE table gives us a method of objectively considering them all, simultaneously.

The Sum of Estimates column in the table enables us to see the total impact of implementing all proposed designs in the project. An alternative to this is to have a cumulative column after each design itself. From the table below we can see that it is estimated that, by implementing all the designs listed, the required performance level increase for Credit Request Capacity will be met to a degree of 85%, for Credit Request Cycle to a degree of 95%, and for Credit Information Response to a degree of 105%. In this latter case it means that implementing all the designs is expected to exceed the required performance level increase for Credit Information Response, again a perfectly possible result!

Monitoring the Project

At the start of the project, the percentage impact figures in the IE table are estimates. It is not the purpose of this paper to discuss how the estimated figures are established but obviously, with every step still in the future then some method of assessment must be used.

As each step is completed, the estimates should be replaced with result metrics in order that the project manager can truthfully report the progress towards meeting the requirements. Hence, Evo insists that the project includes frequent measurements that provide feedback to the estimation process for each step. Even if you start off with guesses, you will find that you soon begin to achieve good estimates through frequent practice. This pays dividends because the estimates that feed the IE table after each step, help to improve the probability of the plan being accurate i.e. determining the next best step in terms of the highest performance to cost ratio.

Other Uses for Impact Estimation Tables

The example shown uses an IE table to determine a sequence of implementation of designs for different functions.

The method can also be used to objectively compare alternative designs, applied to the same functionality. We use the design process to get maximum value for money from our technology. We clearly separate design and consequent value delivery from system business function. Too many so-called ‘function requirements’ are in fact really technical design. In those cases, you are ‘requiring’ something that is not necessarily the best design – the best value for money. You have got to go through the discipline of estimating (later, of actually measuring that you got what you expected), what performance (quality, work capacity, savings), you expect from your design, and what costs you are expecting. This design impact estimation discipline makes you ‘look before you leap’. It makes you bring out clearly whatever you are expecting. It gives you a proper basis for submitting a design to review.

This may include objective assessments, for justifying the development of specific technical structures within the system that do not provide any immediate visual or obvious performance increase to the end users, for example techniques leading to portability, maintainability and security. Those are performance characteristics that are of interest to system stakeholders other than the end users.

You must, of course, allow for dependencies between designs, which always exist i.e. design X must be carried out before design Y can actually be done. By proceeding with the design ideas that give the highest performance to cost ratio you can be sure that you have the best chance of delivering the most cost effective performance increases as early as possible in your project. This method of project planning, or Requirements Driven Management, lends itself perfectly to evolutionary delivery of requirements.

A reassessment of each design idea’s real impacts, at the end of each delivery step, allows the project to change tack if warranted, in a controlled fashion. This is a central characteristic of Evolutionary Project Management.

Scaling Up

Planguage allows the management of multiple requirements simultaneously. The example provides a specification of only three performance requirements. Typically there are lots of key requirements depending on the scale and scope of the project. Managing multiple simultaneous objectives within a project is now possible by means of Impact Estimation, which helps determine which designs provide the most overall performance, compared to the costs of implementing those designs. It scales up, without alteration, to handle the likely numerical limit of your key requirements. Gilb suggests that this is in the range of 5-20. Keeping track of any higher number is less likely to be useful or meaningful. Once you get the hang of identifying your key performance indicators, then you will be able to naturally figure out which are the most important to your organisation or business.

Conclusions

The Use of Planguage on CRM

I have to report that the reaction I received when I presented an Impact Estimation table as part of a project plan for CRM was one of bewilderment! I believe that this was because of the specific circumstances; it was the first time anyone else on the committee had ever seen anything like it, and I attempted both to educate and produce a real plan at the same time. This may have been a mistake. Also, I had introduced it some time during the lifetime of the project rather than at or close to its beginning. In this way, it was extremely difficult to alter the collective mindset of the project’s key stakeholders. So ultimately, I failed to use it as the ‘official’ or primary method of reporting progress and specifying requirements on the CRM project.

However, because I believe the principle to be sound, I continued using the Planguage specifications and plans within the development team in order to maintain the focus of the team’s work on what we deemed to be the key project objectives. This paid off by keeping the technicians minds on the real objective – to deliver the ‘high-value-first’ designs in order to progress towards the perceived desired goals.

An interesting misunderstanding by some members of the committee became apparent when I presented the IE table. It was suggested that some of the requirements could be deemed more important than others. Two important points were being missed.

Firstly, the notion of priority itself was not clearly understood. Gilb’s definition of priority is that it is the "determination of the relative claim on limited resources" [GILB04]. I agree with this definition, not least because of the corollary that if resources were unlimited, then there would be no need to prioritise; all the requirements could be met immediately.

Secondly, if the requirement specifications themselves were to include any notion of priority relative to others i.e. before any design evaluation, then this could only ever be a subjective assessment. It would effectively be no different to deciding on a subjective basis which function to implement in favour of any other. If priority were subjective, then actually there would be no point to objective planning on the basis of specified requirements.

The IE method actually determines the relative claim on limited resources by calculating which design will give the highest Return on Investment. A further advantage of this method is that, instead of relying on arbitrarily fixed weightings, priority is dynamic and can be calculated at the beginning of each step. So, in fact, the IE table is itself the best method of prioritising (see [GILB02]).

Key Advantages of Planguage

Performance Requirements are not necessarily easy to determine but they usually represent the underlying objectives of projects. They are also a more concrete way of monitoring, in measurable terms, how a developing system is bringing increased performance to an organisation. Planguage methods allow clear and unambiguous specifications of these requirements. By doing so, project managers can be released from the straightjacket of a Gantt chart based on specific functions, the precise detail of which can never be fully known in advance.

Project managers and stakeholders must learn that there is no need necessarily to complete every sub-function within a set budget and timescale; the focus must be on delivering increasing performance for the available budget. Specifying Performance Requirements using Planguage allows us to report these increasing performance levels in provable, measurable terms.

Using Planguage to quantify objectives delivers a fundamental advance in managing software development projects.

Acknowledgements

I am indebted to Lindsey Brodie and Tom Gilb for encouragement, criticism, and suggested changes during the production of this paper.
I also thank Tony Ruben and Chris Dale for additional comments.
Finally, this paper is dedicated to Alice Lauren Woodward for helping me in more ways than she may possibly imagine.

References

GILB88: Tom Gilb, "Principles of Software Engineering Management", Addison-Wesley, 1988.

GILB97: Tom Gilb, Requirements Driven Management: A Planning Language, Crosstalk, Software Technology Support Centre (STSC) Department of Defence (DoD), 1997.

GILB02: Tom Gilb, Managing Priorities: Deadline Pressure Control, 2002. {see http://www.gilb.com}

GILB04: Tom Gilb, "Competitive Engineering", Addison-Wesley, forthcoming. {see http://www.gilb.com}

WOODWARD99: Woodward, Stuart, Evolutionary Project Management, IEEE Computer p49-57 (October 1999)

---

More Project Management Knowledge

Scrum Expert

---

Go to page 3   

---

Click here to view the complete list of archived articles

This article was originally  published in the Fall 2003 issue of Methods & Tools