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

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

Problems with Functionality

Had the Requirements Been Met?

The CRM software development project required authorised funding in order to proceed. A committee of senior stakeholders agreed the budget requests. The budget requests were justified by specifying a list of high-level functions to be delivered. For example, a stated requirement was: "the system requires a Credit Approval Process". After the initial phase of the project, the success of each subsequent budget request depended on the whether the deliverables specified under the previous budget were actually made i.e. the request had to state that the project had progressed successfully towards its objective of delivering the previously specified functions.

I was never able to state simply that this had in fact occurred. The high-level functional requirements were broken down into a long list of sub-functions. Under the Credit Approval Process (CAP), for example, were thirty-seven such functional requirement statements. One of these was as follows:

CRM shall initially support the following types of request:

• Transaction
• Counterparty Credit Limit (new)
• Counterparty Credit Limit (existing)
• Counterparty Settlement Limit (new)
• Counterparty Settlement Limit (existing)
• Country Credit Limit (new)
• Country Credit Limit (existing)
• Exception – pre-approved
• Exception – not pre-approved - active
• Exception – not pre-approved – passive
• Policy – documentation record
• Policy – for processing (credit grouping or portfolio limit)

At the end of the project phase in which the CAP was implemented only four of the above types and two others that materialised during the design process had been implemented. When it came to the meeting to discuss the next budget request there was disagreement between the stakeholders on a number of points: on whether the CAP had been implemented satisfactorily, on which types were more important, and on whether the remainder should be deferred or had to be included in the next budget request along with a new list of high-level functions.

CAP was designed to process Credit Requests. Analysis suggested that the capacity of the software to process Credit Requests has risen from 0% to 90% of those that had required processing during the same period. So, although considerable benefit had been brought to the organisation by the enhancement of the system, there was disagreement on whether the originally stated requirement, "the system requires a Credit Approval Process", had been met because not every possible type had been implemented.

Owing to the insistence on reporting in terms of completed functions, the committee felt uneasy about reporting to senior management that CAP had been implemented. It was not even a matter of whether we had used a simple count of sub-functions or a suitable functional sizing metric; there would still have been disagreement. Yet the system did contain a usable CAP catering for 90% of the requests actually raised.

As the Project Manager, I was always under pressure to report progress in simplistic terms of completed functions rather than the enhanced system performance levels. It was therefore difficult to report progress in terms that were universally accepted and the decision by project stakeholders on whether to complete a specific area of functionality before beginning another was always subjective.

What were the Underlying Objectives?

It can be seen that the stated functional requirements were hiding the underlying objectives. For example, during requirements analysis, it became clear that another objective was "to speed up the handling of credit requests", (this is deliberately imprecise at this point). This was never actually documented but materialised as an assumption as to why we were implementing a Credit Approval Process in the software system. Stating the requirement for a Credit Approval Process did not guarantee that the project would necessarily address this underlying objective and gave no method for proving that it had done so.

Requirements or Designs?

The stated sub-functions also became confused with design ideas. For example, one was "The notification shall comprise a Credit Approval Form to be used as the critical evidence of approval and which provides the basis of information for the approval authorities to make their decisions".

Stating a requirement as such proved less than constructive because alternatives existed and were explored. The underlying requirement appeared to be along the lines of "to facilitate the approval
process, the system must be able to assemble quickly all related credit information for review", (again deliberately imprecise here).

Considerable detail inevitably emerged from the function statements as part of the implementation process, which included feedback and exploration of alternatives by the users. This is normal but was impossible to predict at the time of a budget request. It therefore made it impossible to provide a reasonable estimate of the implementation work and corresponding budget required on the basis of stated requirements, which turned out to be design options that were later substituted with others.

It is important not make the common mistake of assuming that technical design is functionality. For example, ‘use a password’ is not necessarily a functional requirement; it is one contributory technical design or solution to a requirement for system security, say, which could be specified in measurable terms.

Iterative Development, Maintenance, or Scope Creep?

A related problem arose when a function, that had already been implemented, required adjustment because it did not work as the users had intended (but were unable originally to specify in functional terms). Often there was the temptation to add more detail or enhance or perfect specific functions. Of course, it was my responsibility as Project Manager to prevent the scope of the requirements from running out of control but it was often difficult to know exactly when to stop the design or implementation process and move on. The basis on when a function is considered completely implemented can be subjective in the absence of other measurements of progress.

I therefore suggest the following: When stating a functional requirement, consider whether alternatives exist. If they do then it might be a design idea to meet some underlying requirement. Try to understand and specify the underlying requirement.

Monitoring on the Basis of Functionality

Monitoring progress purely on the basis of functionality caused further difficulties. Typically, to satisfy the committee, the schedule specified the expected dates of delivery of the high-level functions that were accepted as the project’s requirements. The project’s objective was then to deliver those functions according to the schedule, which represented the time-scale of when the budget began and ended.

Problems occurred when a dependent activity did not occur, or when a dependent resource was not available, at the right time. It was invariably not possible to bring forward in the schedule tasks that were planned for later in order to replace the delayed ones and so manpower was wasted on unnecessary tasks. Monitoring purely on the basis of functionality was wasting resources. The need to completely finish specific functional areas also caused the project schedule to break down. It was impossible to anticipate the fine detail of the full functional requirements at the outset; many sub-functions were not identified until late on.

Also, new design ideas emerged that competed for the available resources. The result was that the time taken to implement each functional area was always longer than anticipated. The insistence of monitoring purely on the basis of functionality was losing the project valuable time. It therefore became impossible to meet the key (functional) requirements upon which the project was authorised. Constant rescheduling was fruitless; it became a vicious circle of subjective reassessment.

The Implication of the Problems Experienced

The basis on which project success is judged should not purely be determined by which functions are implemented; an alternative needs to be considered and the report of planning and progress to senior management must also reflect the alternative method.

Go to page 1    Go to page 3    Back to the archive list