Software Process Improvement (SPI) Best Practices

by Scott W. Ambler

1. Be aware of your organization’s current culture. One of the significant forces that affect the success of your process improvement efforts is the culture of your organization. Organizations with cultures that are positive toward process improvement are likely to want to supply a quality product with reasonable business returns, have middle managers that are willing to set and work toward targets of meeting your organization’s needs and business goals, and have senior management leadership that is willing to launch and sustain a long-term change effort.
2. Expect to change your organization’s structure and culture. Process, organizational structure, and corporate culture all go hand-in-hand – change one and you will affect the others. 
3. Keep it simple. A common mistake that organizations make is to over specify the processes that they intend to follow.  Never forget that your goal is to produce working software that meets the needs of your user community and that your staff likely has a pretty good idea of how to do this although they could help with a little guidance from time to time.  Give them just enough guidance for their needs.  An example of a well defined, yet simply defined, process is the Agile Unified Process (AUP).
4. Align your software process with business goals and objectives.  You could have the best process in the world, but if it doesn’t meet your organization’s goals then it doesn’t matter.  Do you intend to build a portfolio of applications that integrate with, and build upon, one another?  If so then portfolio management is important.  Do you intend to sell shrink-wrapped software to be used by millions of users?  If so then architecture may be less important to you in favor of getting a product to market quickly.
5. Regularly hold retrospectives.  A retrospective is a process improvement meeting where you ask four fundamental questions: What did we do well that if we don't discuss we may forget?  What did we learn?  What should we do differently next time?  What still puzzles us?  Retrospectives can be simple 15 minute discussions or formal meetings over a day or two.  The goal is to learn from your experiences.
6. There's a serious difference between "lessons learned" and "lessons indicated".  The result of a retrospective is a collection of lessons indicated, they don't become "learned" until you actually improve your process.  I've been in organizations where we've held a retrospective, sometimes called a post mortem or "lessons learned" session, which resulted in a list of really good process improvement suggestions.  Always one to cause trouble, I then asked if the client had any similar documents from four or five years ago.  Comparing the documents, we've often discovered significant overlap between the lists.
7. Keep the real goal in mind. My experience has been that software processes, when applied intelligently, increase the productivity of developers. My experience has also been that when processes are applied less than intelligently, or when the paper pushers have too much influence within an organization, processes can also decrease your productivity. Organizations that keep the end goal in mind – that of developing, maintaining, and supporting software that fulfills the needs of their user community – will be successful with implementing software processes. Those that follow processes simply for the sake of doing so are likely to fail.
8. Recognize that the fundamentals remain the same, the details vary. Contrary to popular belief, the fundamentals of software development have been known for many years.  You need to perform requirements engineering.  You need to model.  You need to write code.  You need to test.  You need to perform change control.  You get the picture.  Every successful software organization will have a similar set of processes but the way that your organization brings them in and how they implement them will differ.  Your requirements process may be slightly different than your competitors, but you will both have one that will generally do the same sort of thing.
9. You need more than one process.  You wouldn't run a project team of thirty people the same way that you would a team of three people.  Nor would you run an outsourcing project the same way that you're run a project developed by a co-located team.  Nor would you run a data warehouse project the same way that you'd run a .NET application.  You need different processes, or at least different flavors of your process, for different situations.  Use the right process for the job.
10. Run a trailblazer project to validate your new processes. Regardless of how well you define a process, no process is perfect.  Test your new software process using a trailblazer/pilit project, one that is given the extra resources required to try new techniques and to update them appropriately. 
11. Treat process improvement like a project.  Have an experienced project manager, ideally someone with experience in both process-oriented and object-oriented development. Define the requirements for your processes, model them, implement them, test them with a trailblazer project, and then improve the processes.
12. Improve your processes in priority order.  The reality of process improvement is that you cannot make all of the changes that you want to immediately; it is simply too great a change for your organization to absorb at once. This is why we have efforts such as the Software Engineering Institute’s (SEI’s) Capability Maturity Model Integrated (CMMI) efforts and the Software Process Improvement Capability Determination (SPICE) efforts of the International Standards Organization (ISO). Both of these organizations suggest that you prioritize the process improvements that your organization needs to make, expect that it will take several years to make the needed changes, and expect that you will experience difficulties while doing so. There are five maturity levels in the CMMI for a reason: you need to progress in order from level one to level two to level three and so on.  The implication is that by knowing which aspects of a software process map to which CMM maturity levels you have a rough idea of the order in which you should introduce those processes to your staff.  Experience shows that organizations that try to make immediate, large-scale process changes are likely to fail doing so. The reality is that it takes time, often several years, to permanently improve the productivity of your software development efforts. There is not a simple, quick fix to your problems. 
13. Communicate your plan.  It is essential that you let others know what are you doing, why are you doing it, the business case for it, success stories, etc. Keeping them informed on how things are going, even if you are encountering difficulties, will help get them (and keep them) on board. There are various options for this: a newsletter, a web site, periodic emails to key personnel, etc. Trumpet your successes and share your lessons learned with the appropriate people.
14. Accept that the big picture is overwhelming.  Because of the complex nature of software development most developers specialize in one aspect of it and focus solely on that.  This becomes a problem for organizations that wish to tailor a software process for their exact needs because when they put the individual pieces together the overall process becomes very large.  For example, the Rational Unified Process (RUP) is over 3,000 HTML pages in size, and it is only a development process.  Once developers see how large your organization’s software process is they often go into denial, claiming that you can not possibly achieve your goals.  Yet when you ask an individual which part of their process they can simplify they’ll often balk at the idea.  An alternative approach might be something such as the Agile Unified Process (AUP), which is a bit smaller (it's around 30 HTML pages).
15. Democracies do not always work, nor do dictatorships.  Organizations that wish to reach consensus regarding their software process tend to flounder. You’ll never achieve complete agreement on how things should be done, although organizations that dictate processes from above tend to fail as well.  Effective process improvement efforts seek consensus at some points and dictate things at other points.
16. Identify the consumers and suppliers for each process.  Every process has inputs and outputs, and you need to ensure that there is a supplier for each input and a consumer for each output.  Fundamentally, if nobody is going to use an artifact that is produced by a given process then why bother producing it?  You also need to look at collections of processes to see if the artifacts that they produce add value in combination.
17. Defining a process is the easy part. Many organizations are very successful at defining a software process, often producing binders (or web pages) of documentation.  However, when I've revisited these organizations a few months after introducing a new process it will be all but forgotten.  Getting people to accept your new process, and making the changes that go along with it, will take significant time and effort to accomplish.  Writing a process is the easy part, following it is the hard part.
18. Introduce a Software Engineering Process Group (SEPG) to your organization. The sole responsibility of your SEPG is to support the definition and improvement of your organization’s software process. The SEPG should be kept small – as a rule of thumb, we suggest one SEPG member for every one hundred developers in your organization.  SEPG efforts are a component of the EUP's Software Process Improvement (SPI) discipline.
19. Staff your SEPG with actual practitioners.  The people who best understand how to develop software are the people who are very good at developing software.  Yes, that sounds blindingly obvious, but what isn't obvious is that they are usually the best ones suited to define your software process.  Try to staff your SEPG mostly with current practitioners, people who are now managers but had did some COBOL programming 20 years ago are often poor candidates, although include some people with a process background to ensure that they're not reinventing the wheel.
20. Reuse existing process materials.  There is a wealth of process materials out there, you very likely don't need to write your own.
21. Avoid “fire hazard processes". A common mistake is to produce volumes of documentation describing your processes. Your goal is simply to describe your process materials to such a level that they can be given to a professional skilled in the techniques of that process so they can work the processes appropriately.
22. Adopt processes because they make sense.  If a process makes sense to you, and you believe it will add value to your effort, then adopt it.  Otherwise, do not.
23. Hold everyone responsible for process improvement. Senior management must be willing to actively support and sustain process improvement, project managers must be held responsible for ensuring that their teams follow the defined processes, and developers must be held responsible for learning and then following the processes. This is often a difficult task because senior management often demands immediate results, whereas process improvement often takes years. Project managers resent diverting scarce resources from their projects, and developers often resent being told how to do their jobs.
24. Bring in an expert to advise you. Process improvement is a complex and difficult endeavor, one for which you are likely to need help to accomplish. You can increase your chance of success by bringing in a consultant who has both a process background and an OO development background – someone who has been actively involved in a process improvement program and who has worked on large-scale, mission-critical software development projects using OO technology. 
25. Do not think that everyone is on board. There is likely to be a small core of people within your organization who do not want to use object technology for large, mission-critical projects, and these people will actively undermine your efforts. You need to identify these dissenters and work together with them to help them see the advantages of working with object technology and of following a set of defined process patterns to help in the development OO software.
26. A fool with a process is still a fool. For your organization to be successful with a software process your software professionals will need to understand the processes, the concepts, the techniques, and the problem domain. Implementing a new process in your organization involves more than going out and purchasing a couple of new books and development tools.
27. Develop a user guide for your process. You can make it easy for your staff to learn your chosen processes by providing a well-written overview of your process as it is to be implemented in your organization.  In fact, this may be all the process material that you need.
28. Have patience. Progress will be slow at first, slower than you hoped or expected. Introducing a software process into an organization takes time – the required culture shift often takes years to complete.
29. Don’t flounder in bureaucratic requirements.  Too many process efforts run aground because of preconceptions forced on them by senior management, an overly burdensome documentation and review process, or unrealistic requirements to achieve consensus.
30. Define your process early.  The longer you leave process definition the bigger the mess you will have to clean up.  Without direction, developers will typically go and do what they think is right, the only problem being that each person has their own idea of what “right” is.

Time Management

by Dr. Ben S. Graham, Jr.
The Ben Graham Corporation
© The Ben Graham Corporation, 1996

Permission is granted to post, print and distribute this document in its original PDF format.

Everyone has the same twenty-four hours each day, yet some people accomplish many times more than might be considered normal. Surprisingly, these people often appear calm and unhurried. Without driving themselves, they have mastered the art of managing their most valuable resource, their time. They have arrived at constructive attitudes and have polished skills for making the most of their time. This session includes a discussion of the psychology and the techniques of time management.

The Psychology of Time Management

It is one thing to learn a technique and apply it diligently. It is quite another to understand why a technique works and be able to apply it creatively. This presentation offers a couple of techniques for making better use of time but first it covers why these techniques work. Unfortunately, our minds invite misunderstandings about time that interfere with our making the best use of it. This discussion of the psychology of time management is intended to clarify these misunderstandings and prepare us to become the masters of our time.

Doing Everything We Have the Chance to Do
People develop their first notions of time early in life when there is relatively little that they can do. It is natural for parents to restrain young children to protect them from getting into things that would be dangerous and this, of course restricts the number of things they can do. As young children begin to learn about minutes, hours and days, time seems long. And, time seems sufficient to do all the things that they are allowed and able to do. It is not at all unusual for youngsters to want to do more things and for parents to keep restraining them.

Increasing Pressure on Time
Having enough time to do everything that we have a chance to do continues through childhood for most children. However, the number of things that they are able to do and allowed to do steadily increases. The amount of time that we have for doing things does not increase. The twenty-four hours that was ample for doing everything for the youngster never gets any longer. By the time young people reach early adolescence most of them begin to find that they want to do more things than they have time to do.

For instance, in elementary school all of the children take all of the same subjects. When they leave the class-room for recess in the school yard they are all apt to play the same games. Then when they reach junior high school they find that there are more classes than anyone is able to take. Perhaps they will choose between a trade program or a college preparatory program. Will they take a language? Which language will it be? They can't take both art and music. Which will it be?. After school, in the afternoons, there are other choices. Will the get involved in school clubs? Will they try out for sports? Will they hang around - with whom, - where - smoke pot - get involved in church activities? They are faced with many decisions. How they face these decisions determines their success with the identity crisis of adolescence.

The key to this identity crisis is the decision-making. However, facing up to the idea that we can't do everything is uncomfortable and some people have a lot of trouble with it. As time marches on they do not decide. They promise themselves that someday they will do this and do that and go to all the different places, etc. Rather than making up their minds they waste their time while they carry psychological baggage that includes all of the things they will get around to doing someday.

This is a much greater problem for people as we approach the twenty-first century than it was for people in prior generations because there are so many things available for us to do today that were not available then. Television was not available when our grandparents were children and is now available in so many channels that the impossibility of watching them all is obvious. And, television is just a part of the vast array of entertainment that is available. Magazines and books are available on almost every subject. Everywhere we turn there are people telling us we should get involved in this exercise program or join this time-sharing program, attend this professional meeting, get involved in these "do-it-yourself" projects, or another hobby, some totally worthwhile cause that needs our involvement, and on it goes. No population has ever been so barraged with enticements to do so many things as we are today.

And, still there are people trying to do it all. They subscribe to magazines that they do not read and then when the renewal notice arrives they sign up again. Heaven forbid that they should miss an issue that they will stack up and not read.

At the heart of this issue of increasing pressure on time is the obvious need to make choices. But, this is only a part of the fascinating subject of mastering our time. Next we will deal with the elasticity of time.

Elasticity of Time
Scientists and engineers have gone to great lengths to provide us with instruments that measure time with extreme precision. Every minute is exactly the same as every other minute. However, as we experience time the minutes are not all the same. Some minutes seem to take forever and some seem to flash by. The key to understanding the elasticity of time is interest. The more interested we are in what is happening, the faster time seems to pass. Conversely, the more disinterested we are, the more time seems to drag.

Most people have personally experienced this relationship between interest and the passage of time. They know what it is like to be doing something that has them so involved that they are suddenly shocked at what time it has gotten to be. They also know how frustrating it is to wait, to stand in line doing nothing. In fact, they know the irritation they experience when someone cuts into the line. Waiting can seem to take so long that it tries our patience. Then when someone adds to the wait, patience may run out. More than one person has flown off the handle in this situation.

Most people also know what it is like to be sitting in an audience listening to something that is totally boring. How, long it seems to take. "Will this never end?" Meanwhile, someone else in that same audience may be very interested in the subject. The person who is interested may wish the speaker would slow down and repeat something again and if he does the person who is bored will be thinking, "Oh no! He's saying it again! He's said that three times already and I wasn't interested in the first place." Suffice it to say that all minutes contain the same amount of time but the same minute may seem totally different to two different people depending on their interest.

Selective Memory
The elasticity of time would be of little interest to the subject of time management except that it is directly related to memory Memory in turn sets the stage for the time trap that steals our time. Here is how that works.

The less involved we are with any given activity the slower the time seems to pass. Ironically, The slower the time passes the less we will remember it. The more bored we become the less energy we give to the task and the less brain work we do building the linkages that will enable us to get back to that experience again.

Conversely, the more involved we are with any experience the more energy we expend on the brain work that enables us to relive that experience over and over again even many years later. For instance, most people can remember small details about particular experiences such as a graduation day, a wedding day, the birth of a child, attending a super bowl game, being in an automobile accident, the loss of a loved one, etc. What all of these activities have in common is that they had us intensely involved.

One experience that can be used to illustrate this point for many people is the assassination of President Kennedy. Many people remember, with exact detail, where they were when they heard about it, what they thought, what happened next and on through the events that followed over the four days. Even though this occurred over thirty years ago, many people can still remember it much more vividly than they remember what happened thirty days ago.

As a matter of fact, there is a detail associated with the Kennedy assassination that is quite unique and can help us to understand this relationship of involvement with memory on an even higher plane. It goes like this. In the United States there are many suicides every day. It is a big country and therefore every day forty or fifty, or a hundred people decide to kill themselves. We simply do not have days when nobody commits suicide. But we did! In November of 1963 we not only had a day with no suicides, we had four consecutive days with no suicide and they were the same four days that we associate with the Kennedy assassination. Coincidence. Not a chance! No one did themselves in during those four days for the same reason that so many people can remember those days so clearly today. We were involved. We were doing what human beings are supposed to do. We were intensely involved, fully alive and using our faculties as they are designed to be used.

For the moment this is a discussion of memory and it seems appropriate to digress briefly on this important subject. Most people would like to be able to remember well and perhaps, to improve their memories. There is a very simple way to improve your memory. It is to get excited about your life. If you find yourself bored with your life do something about it. If your find yourself going through the motions of living cut it out! Dig into your life. Dig into your job. Whatever you are doing, do it with zest. And, if you find yourself at a dead end after giving it your best effort, then make a critical decision to change where you are. But, what ever you do, live your life. Be alive, be excited and you will find that you will remember.

The Theft of Time
Because we remember the things we are highly involved with and do not remember the things that bore us, our memories are comfortable. The activities that we remember were important. The time we wasted we do not recall. This can help us to feel good about ourselves but it also enables us to squander our lives without realizing it. It is as though we are being robbed of the most valuable asset we have, the time of our lives, and we don't even know it is happening.

Summary of the Psychology of Time Management
First, we need to realize that we cannot do everything. Certainly people can be involved in a wide variety of activities and still live highly effective lives but they must make decisions that give a central course to their lives and they must keep getting back to that course. Then It helps to realize that our memories play tricks on us as we remember our actions as being more important than they really are. Once we have these two thoughts well in mind we should be ready to try out some of the techniques of time management. And, if we do it well, we may become the masters of our time.

Techniques of Time Management

The A B C Approach
Developed by Don Schoeller at the Wharton School during the 40s and 50s, The ABC Approach to Time Management operates as follows. First you list the things that you do with your time. Then you sort them into highly valuable, "A", intermediate value, "B" and low value, "C". Then keep track of your time for a day or so. Then total up the amount of time that you spent involved with activities of each of the three categories. Don Schoeller worked with managers and engineers in his classes in the extension program at the Wharton School. When they collected this data they found that they were invariably spending more time on class "C" activities than they thought they were and considerably less time on class "A" activities.

Don assembled data that showed that these managers and engineers were spending about fifteen percent of their time on their valuable activities, twenty percent on the intermediate activities and around sixty-five percent on low value activities. If this is the case, then it is easy to see how a person could double the time spent on valuable activities and still be using only thirty percent of his or her time on them. Why not go ahead and double it again. As for the low value activities. Many of them simply aren't worth doing. Those low value activities that must be done merit study to find the fastest and easiest way of doing them so that our time can be freed up for more valuable activities.

This is, essentially, the Work Simplification approach that attacks time-consuming tasks in order to free up time for more valuable accomplishments. It also helps to explain how it is that some people get so much done in their lives while others, in the same amount of time with similar opportunities accomplish so little.

Work Distribution Charting
This technique is an adaptation of the ABC Approach for use with a group of people who work together. First they make a list of their activities, making sure that they all break down the work into the same sorts of activities. Then they keep track of their time for a day or two and they total the time spent on each activity. Then one of them prepares a spread sheet listing the people across the top and the activities down the side. In the intersections they post the total time that each person spent on each activity. When they total horizontally, across the spread sheet, they can see how much time they have spent as a group on each activity.

This information is usually unavailable for two reasons. First, as individuals they cannot remember how much time they spent on each activity and second, even if they did, they would not be able to remember how much time the other people spent on each activity.

Once this information is available, there may be some surprises. Often, low value activities are found to be tying up far more time than they are worth and this puts a challenge before the group to figure out how reduce that time. Sometimes reports can be discontinued. It helps to convert the time to dollars' worth of time and put a price on the report. Is it worth it? And, it should be understood that if the report is discontinued it will not mean that that amount of money will be saved. It will mean that that amount of time will be made available for more valuable activities.

Summary

Time is our most valuable asset! Yet an enormous amount of it is squandered. (And, the squandering is based on the values of the person who is wasting the time, not on the values of someone else.) We waste our time partly because we tend to think we have more time than we do and partly because we don't remember the time we waste. It helps to let a clock tell us how much time we are spending on our different activities. The nice thing about using a clock is that it is objective. It does not care whether we are doing the most important thing in our life or absolute trivia, it counts each minute the same. Then each of us needs to make decisions about what we want to do with our time and get on with living and mastering our lives.

Controlling Change Requests in Projects

By Michelle Symonds

Changes requested once a project is underway are an inevitable part of any project. They can either be the result of external changes in the business or they can be internal changes requested because the original aims of the project were not clearly defined or understood.

Change requests resulting from external factors are usually beyond the control of a project manager and there is usually little choice but to deal with them. Most successful project managers will have already put a process in place at the start of the project to handle such requests and the plan will be flexible enough to cope without unduly affecting the final outcome.

But change requests resulting from internal factors should be handled very differently. In an ideal project many of these would have been avoided by ensuring the project objectives were well-defined, the requirements were clearly documented and communicated to all stakeholders, and the stakeholders understood what to expect from the final product. Of course, we don't always live in an ideal world and no matter how thorough and detailed the initial stages of a project are there will always need to be an effective change process in place.

Not all stakeholders and end users can visualise an end-product by reading documentation and studying diagrams. Even when prototypes are used to enhance the production of the requirements they are, by their nature, not fully functioning products and misunderstandings and assumptions will be inevitable on complex projects.

Nevertheless, good documentation and clear communication of the project objectives and requirements will minimise the number of change requests.

So what is the best way of controlling change requests in a project and still being able to deliver the completed project within an acceptable budget, time and scope?

Distinguish Between the Necessary and the "Nice-to-Have"

Every change request should have a business case to back it up in the same way the overall project had. Of course, this can be a very simple and short description, but is a necessary element of all change requests before they can be considered for inclusion in a project.

The most important element of the change request business case is the expected benefit, which should indicate the value that will be added to the project by the change. This, in itself, will indicate which changes are likely to be necessary. It is important to recognise the description of some business cases may not necessarily benefit the project in terms of time and budget, but are necessary for the client to remain competitive in their marketplace.

If the benefits are not explicitly stated then discuss the issue with the person who requested the change to determine if there is a genuine business benefit.

Better designed solutions, or nicer, more attractive features are not benefits unless they can be backed up by how this will have a positive impact on the project budget and schedule, or a positive impact on the end-user's effort required to complete regular tasks. Typical questions the business case of a change request should answer are:

• "What external business change has resulted in this change request?"
• "What internal factor has resulted in this change request?"
• "How will this change affect the time taken to complete the project?"
• "How will this change affect the use of the end-product?"
• "What cost-savings will be made by implementing this change?"

Avoid Wasting Time and Effort

The most obvious way to avoid wasting valuable project resources on excessive change requests and the whole change management process, is to ensure the project starts with clearly defined objectives and requirements. It is also important the criteria which will be used to determine project success is documented succinctly at the start of the project. Ensure all of these documents are distributed to stakeholders and end users and that copies are easily accessible.

Schedule time into the project plan for dealing with change requests and if that time has been eaten up then defer outstanding requests until the following week. Ensure that all interested parties know this is how the process works.

Have Clear Acceptance and Rejection Criteria

Use some clear criteria to screen out those requests that will not, or cannot be, implemented. One essential criterion is a business case, so any request without one can immediately be sent back to the requester. Do not waste time tracking down the requester to find out what the business case is. It should be their responsibility to provide it initially (even if you later need to have discussions to refine it).

Be prepared to back up your reasons for rejecting change requests with a well-thought out description of why there is no case to include the change. Stick by your decision unless the project sponsor is prepared to increase the budget or time available for the project.

But do be prepared to be flexible and negotiate a trade-off by dropping a planned task in favour of the change when no budget or extra time is available.

Always apply project management best practices throughout every area of a project if you want the highest chance of success.

The Purpose of Project Management and Setting Objectives

By Brian Miller

Project Management has developed in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects. All projects share one common characteristic - the projection of ideas and activities into new endeavours.

The purpose of project management is to foresee or predict as many dangers and problems as possible; and to plan, organise and control activities so that the project is completed as successfully as possible in spite of all the risks. The ever-present element of risk and uncertainty means that events and tasks leading to completion can never be foretold with absolute accuracy. For some complex or advanced projects, even the possibility of successful completion might be of serious doubt.

Project management can involve the following activities: planning - deciding what is to be done; organising - making arrangements; staffing - selecting the right people for the job; directing - giving instructions; monitoring - checking on progress; controlling - taking action to remedy hold ups; innovation - coming up with new solutions; representing - liaising with users.

Setting Objectives

Effective objectives in project management are specific. A specific objective increases the chances of leading to a specific outcome. Therefore objectives shouldn't be vague, such as "to improve customer relations," because they are not measurable. Objectives should show how successful a project has been, for example "to reduce customer complaints by 50%" would be a good objective. The measure can be, in some cases, a simple yes or no answer, for example, "did we reduce the number of customer complaints by 50%?"

While there may be one major project objective, in pursuing it there may be interim project objectives. In lots of instances, project teams are tasked with achieving a series of objectives in pursuit of the final objective. In many cases, teams can only proceed in a stair step fashion to achieve the desired outcome. If they were to proceed in any other manner, they may not be able to develop the skills or insights along the way that will enable them to progress in a productive manner.

Objectives can often be set under three headings:

Performance and Quality

The end result of a project must fit the purpose for which it was intended. At one time, quality was seen as the responsibility of the quality control department. In more recent years the concept of total quality management has come to the fore, with the responsibility for quality shared by all staff from top management downwards.

Budget

The project must be completed without exceeding the authorised expenditure. Financial sources are not always inexhaustible and a project might be abandoned altogether if funds run out before completion. If that was to happen, the money and effort invested in the project would be forfeited and written off. In extreme cases the project contractor could face ruin. There are many projects where there is no direct profit motive, however it is still important to pay proper attention to the cost budgets, and financial management remains essential.


Time to Completion

Actual progress has to match or beat planned progress. All significant stages of the project must take place no later than their specified dates, to result in total completion on or before the planned finish date. The timescale objective is extremely important because late completion of a project is not very likely to please the project purchaser or the sponsor.

Conclusion

Project management has developed over the years, and involves various activities before a project is completed. Objectives should be specific so they are measurable, and although there may be one major project objective, there may be minor objectives throughout the project.