Hard rules for software 

By David Braue 
June 24 2003 
Next 

After spending millions on the development of its new core software  application, the client thought something funny was going on when the developer  company presented an application it said was 90 per cent complete - but worked  nothing like it was supposed to. An outside assessment of the program found it  to be only about two-thirds finished; the developer had been lying about its  progress to appease the increasingly stressed client company, which canned the  project when told completing the application would take another two years. 

Observers would think the information technology industry would have matured  past this, but petty deception and systemic misunderstanding continue to plague  many software development projects. 

Blatant disregard for the basics of project management often poisons the  relationship between customer and supplier. 

In studying 13,522 IT projects the Standish Group's CHAOS Chronicles Report  found that only 34 per cent of projects are deemed successful, and 15 per cent  of all projects were cancelled. 

Of the remaining 51 per cent the average cost overrun is 43 per cent, down  from 180 per cent in 1994. Some 82 per cent of projects run overtime and only 52  per cent of required features and functions make it to the released product. The  impact of the problem is significant. Standish estimates a total waste in the  United States of $82 billion last year out of total project spending of $382  billion. 

Alan Read, IT partner at business consulting firm Abbott Stillman &  Wilson, has seen it all before. Initially a telecommunications industry lawyer  and now called in as arbitrator in often tense contract negotiations, Read says:  "There are a lot of people who are not putting in the groundwork to get it  right. Most people assume the software will do what they want, then find that as  the project evolves they learn more about what it does and doesn't do. 

Everyone starts off these things with the best intentions but it tends not to  take long before things start to change. You need support from higher management  to make sure it doesn't go off the rails." 

When it does, the results can be catastrophic. In February, the Victorian  Government completed payment of a $65 million settlement to ERG subsidiary  OneLink after changes made to the project design at a late stage blew out the  budget of OneLink's Melbourne public transport ticketing system rollout. And,  this month, RMIT University announced it will take another shot at making its  disastrous Academic Management System work. The system, which was to be based on  PeopleSoft software, has already cost the university $48.6 million and is  nowhere near completion. 

Software developers and consultants have long sought to educate clients about  avoiding miscommunication, but many poorly trained project managers simply lack  the expertise. 

"The basic principles of project management are often missed by people who  believe they know what they're doing," says Heinz Haselroither, Victorian  chapter president of the Australian Institute of Project Management. "They miss  some of the major items such as focusing on completion, defining the scope of  work, setting basic aims, and using procedures to orient the project towards  achieving these aims. Many people simply fall into doing the job of project  manager without being trained to do that job." 

Such managers will have a clearer set of guidelines to follow, however, now  that the International Organisation for Standardisation (ISO) has approved  ISO/IEC 20926, a measuring standard based on an application's function points,  such as printing a document or processing an invoice. In April, the ISO also  approved ISO/IEC TR 14143-3:2003, the third part of a methodology standard. 

By assessing a proposed project in terms of function points, a tenderer can  give bidders a clear indication of the size and complexity of the application.  Bidders can then fix a cost for each function point for the finished application  - a rule of thumb is $1000 a function point - that can be used to evaluate  project costs and to introduce additional charges if the scope exceeds initial  estimates. A moderate-sized application might have 400 to 500 function points,  and anything over 1500 is entering high-risk territory. 

Pam Morris, managing director of scope management firm Total Metrics, was  closely involved in the completion of the standard through her affiliation with  the International Function Point Users Group (IFPUG) the International Software  Benchmarking 

Standards Group (ISBG), established in Australia in 1993, and the Australian  Software Metrics Association. Total Metrics works as an independent judge of  project development, applying strict methodologies to gauge the complexity of  applications as they progress. 

The function point assessment process can be completed within a few days but  can be immensely valuable in deciding whether projects are adequately defined  before development: "Very few people introduce metrics as part of their project  monitoring and even fewer size their projects up front," Morris says. 

"If they did, they would often not proceed because the up-front size would  immediately tell them they were in a high-risk area. Once you get over 3000  function points, the risk of cancellation is around 50 per cent. When they  realise that, many companies decide to do a phased implementation. When the  process is employed correctly, we find the projects are very successful." 

Standardisation could help eliminate the miscommunication that has damaged  projects such as one in which Morris was recently involved, where the supplier  claimed to have delivered 75 per cent of the components it had been contracted  to supply but a function point assessment revealed the components had delivered  only 20 per cent of the application. 

By helping all concerned parties set out expectations, such methodologies  provide a valuable weapon in the fight against scope creep and budget  blowouts. 

IBM introduced the Capabilities Management Model framework several years ago  after it was sued by the New Zealand government over a project that had  stretched to three years and exceeded the budget by $30 million. 

Finger-pointing was rampant, with the New Zealand police said to have made  more than 900 variations to the original 10,000-page contract and IBM saying it  had already lost $40 million on the ill-fated application. In the long term,  IBM's experience with the project - along with a similarly disastrous project  for Telecom New Zealand that was also canned - has driven the company to make  its development processes much more vigorous. 

"A lot of the emphasis in CMM is about requirements management at the early  stages," says David Norris, general manager of IBM Global Services Australia's  application management service group. 

"It's inevitable that as a project progresses, the level of understanding by  the development team and customers tends to increase; there is a natural  tendency to have projects expand rather than stay on their quote. But since  we've been running CMM, we've achieved around 98.5 per cent on-time delivery and  99 per cent on-budget and we would (attribute) a lot of that to the use of  CMM." 

There is no lack of options for project managers to consider when searching  for a method of managing scope. 

Whether their adoption delivers great improvements in quality will depend on  how well they are used but at the very least they provide a more rigorous  standard by which the still-evolving field of IT project management can be  measured. 

Functional points 

Victoria's Department of Human Services (DHS) saved itself time and money by  using function points to streamline the recent development of Lotus Notes  applications. 

The DHS used southernSCOPE, a function point-based methodology, developed by  the State Government. Government testing has found that projects using  southernSCOPE ( www.mmv.vic.gov.au/southernSCOPE )  are successfully completed, meet business needs, cut budget overrun to less than  10 per cent on average and are value for money. 

Working with Total Metrics to track its progress within southernSCOPE, the  DHS was able to stipulate what it wanted from the Lotus Notes applications,  which were 

intended to give nearly 40 reception staff at nine offices access to a  departmental staff directory, telephone messaging, staff in/out board and other  features. 

Rather than rushing into development, the DHS, working with developer  Groupware Consulting ( www.gw.com.au ) and  Total Metrics as scope managers, spent some 55 per cent of the project's time in  the analysis and design stages and just 34 per cent of its time in actual  development. DHS project manager Chris Carter says spending so much time on  design (industry figures suggest an average of 35 per cent) paid off. 

"What this means is that people cutting code were never sitting around  twiddling their thumbs, waiting for management to make up their minds about this  or that," Carter says. "That's the expensive part of development. When we went  to the Victorian government panel of contractors, quotes were taken on a  dollar-per-function-point basis. Starting with a well-defined metric of the size  of the application, there shouldn't be any hidden traps. At an early stage, you  can say 'That's much more expensive and larger than we had budgeted or  imagined', and you can do the project in a much more iterative way."

Article Questions

1.	What sort of projects are being discussed in the article?
2.	What do you think are ‘the basics of PM?’
3.	According to CHAOS Chronicles Report, comment on success rates, timeliness and efficiency of projects.
4.	Name 2 examples of recent local projects that have failed dramatically.
5.	According to Heinz Haselroither, what are some of the basics of PM.
6.	What does the Organisation for Standardisation (ISO) do?
7.	What relevance does the ISO have in defining a project?
8.	What does this mean: "function point-based methodology"?
9.	What do you think these phrases mean: "scope creep" and "budget  blowouts".
10.	Why did IBM develop their Capabilities Management Model(CMM) framework?  Has it helped?
11.	How long did DHS spend on analysis and design, and development?  What implications does this have?