Knowledge Works and Project Control

Sunil Sharma - January 28, 2003

'Let’s say that you are developing an information system--an integrated program--that is forecasted to have 20,000 lines of code and would take four weeks to finish. Let’s also say that you have written 15,000 lines of code. What would you say about the status of your program? Is it 75 percent complete? What if you have taken three weeks to write the code? Would you again say that it is 75 percent complete? Would you also say that you are on schedule?

 

Now consider that you are building a house with four rooms, each of 200 square feet, and you have estimated that it would take you four weeks to build the house. Now let’s say that you have finished three rooms. Is your house 75 percent complete? What if you took three weeks to complete three rooms? Is it 75 percent complete and on schedule?

 

The answers to the second set of questions are simple. The house is 75 percent complete and on schedule. But the answers to first set of questions are not so straightforward. A semi-finished computer program does not give a clear idea about the quality of the work, nor does it give any idea about the scope, whereas a semi-finished house does give a clear idea about the quality and scope of the work.

 

Even though 75 percent of the estimated lines of code has been written, one cannot say for sure that the finished program would work, which means that you could not determine the quality of the work. Also, 20,000 lines of code is just an estimate, and the actual lines of code needed to finish the program could be more or less.

 

Similarly, you may have taken three weeks to write 15,000 lines of code, but that does not guarantee that the remaining 5,000 lines could be written in one week. It depends upon a number of factors, including new code versus derived/reusable code, finding logical answers to problems that can’t be accurately estimated in terms of time because they involve abstract working of the mind.

 

James P Lewis, author of Project Planning, Scheduling and Control, says 80 percent of the work will be consumed by 20 percent of the problems. For a computer program it is not always possible to linearly allocate time to the lines of code written; the program could use reusable or derived code that may not take the same amount of time to write as is needed to write a new code.

 

On the other hand, the details about building a house are quite fixed. Four rooms, each of 200 square feet, provide us with accurate measurements. Also, most of the factors influencing the construction of a room can be accurately judged (except things that may be dependent upon outside factors like weather). So unlike a semi-finished program, a semi-finished house does give you precise idea about the quality and scope of the finished work. Hence you could accurately state its progress in terms of percent completion.

 

Measuring and Controlling SW Programming--The Knowledge Works
So does this mean that we should not attempt to measure progress in programming? That is not a practical solution. “Knowledge Works”--to use Peter Drucker’s term--like computer programming, is harder to measure as compared to physical works. But we must measure and control them.

 

By nature, programming or knowledge works pose a number of challenges for control and measurement. One of them is comparing performance against plan, as the work is not quantifiable. How do you know what percentage of programming is completed? Is it 75 percent complete when 75 percent of the features are completed, or when 75 percent of the lines of code have been written?

 

In the initial plan for a SW project, the number of lines of code are just an estimate. The finished program may have more or less lines of code. On the other hand, the plan may give you a fixed number of features and functions, but all of them may not have the same level of scope or complexity. Also, the complexity of programming units and their overall scope could only be stated in approximated terms.

 

This means that since knowledge works are not easily quantifiable, we have to use estimates to monitor their progress. But estimates are subjective and project control needs objective data.

 

A point that experts make about knowledge works is that though quality and scope do not provide objective data, the cost does--you know how many hours have been put in for the work. Hence, some managers employ methodologies that utilize cost (and labor hours) spent as a means to monitor and control the project. Using cost and time you could tell exactly how much time or money has been spent on the job, but you would not be able tell how much of the work has been completed or how much of the work is yet to be completed. You could only give estimates for them.

 

Thus, subjective data (quality and scope) and objective data (cost and time spent) need to be considered together to measure and control SW programming or the knowledge works.

 

Using cost and time, you find out exactly how much time or money has been spent on the job. Then you estimate how much work is completed and how much is left. By considering these two sets of data, you could determine if your knowledge works project is on time or behind, and whether it is over budget or under. In this approach, the project control is based upon the completed work and the progress is measured by examining the product.

 

Chunking and FPA to Measure and Control
In one of his books, James Lewis makes a suggestion that programming and engineering work should be sub-divided into one- to three-week increments with milestones to tell you if the increments have been completed. Chunking a project like this would be effective if you could sub-divide the work based upon the functionalities of clearly definable deliverables. In this scheme, when a milestone is reached and the work is completed, you credit the person doing the work.

 

Another method that is used to measure software application is Function Points Analysis. FPA provides a metric to measure the size of the software. In addition, it is also useful in estimating the project and managing the scope-change. The function point method considers data handling (internal files and external interface files) and transaction processing (input, output and inquiry) within an application. Based upon certain criteria, it assigns the function point counts. To a large extent, these counts give a good idea about the scope of software to be developed.

 

Project Control System
Chunking and FPA bring some objectivity to the subjective nature of SW programming. Measuring the software is only one dimension of the project control. FPA and chunking would help you in measuring the scope of the software to be developed, but they are not sufficient to form the complete project control system.

 

A project control system is a tool that enables managers to recognize problems before they become unsolvable. In essence, it monitors and controls the actual work to be done along with the cost of doing the work and the time needed to do it. How elaborate a system is depends on the size and scope of the task to be managed, as well as the size and distribution of the team working on it. The next feature of the series will focus upon the components of a project control system.

 

Strategic and results-oriented, Sunil is an entrepreneurial consultant who had founded a B2B ASP for the building & construction industry. His area of expertise includes strategic management, marketing and business planning for high-tech firms. He publishes a business and marketing planning e-newsletter. An avid mountain climber and runner, Sunil has climbed Mt. Kilimanjaro and various peaks in the Himalayas, and finished the Detroit marathon. He holds an MBA degree from the University of Michigan, Ann Arbor, and a BS in Electronics and an MS in Mathematics from the BITS, Pilani, India. He can be reached at (703) 395-9812 and at [email protected].

Related Content

---