Introduction
Software development presents a different challenge compared to most other types of projects. After being a professional developer for several years, it became more obvious to me when I started managing the folks who actually did the work. In most other types of work, it is very clear what the requirements are up front:
- They are not subject to frequent change.
- It is very rare to have side effects from one part of the work product causing strange behavior elsewhere.
The software industry has become very enamored of the construction and manufacturing industries. I remember that one of the buzzwords early in my career was the concept of the software “factory.” The belief has been that constructing software is similar to constructing buildings or producing goods in a manufacturing plant. Unfortunately, nothing could be further from the truth. It is not normal in the construction or manufacturing industry for specifications and design to change during construction or production. If they do, they have cost overruns that put any of our over-budget software projects to shame. Until recently, I lived in Boston where the fabled “Big Dig” project has cost overruns into billions of dollars and is still counting!
Changing Requirements for Software Development
This “fluidity” in requirements makes it a challenge to successfully manage software projects. Managers who use construction or manufacturing as a guideline frequently underestimate the problems it causes teams as well as the huge costs involved in terms of freezing requirements too early. Neither the employees nor the organization reach their full potential.
I recently met several senior managers as part of a survey to identify what issues caused them the most heartburn. It was no surprise to see requirements uncertainty as the top issue. In defense of management, it must be said that one of their primary jobs is to ensure predictability and reduce unpleasant surprises. Managers who have difficulty ensuring either will be looking for new jobs fairly soon! It is no wonder that with such constraints, management puts a premium on being able to predict and manage project goals and dates.
However, the tools and techniques that may work so well in traditional industries are frequently inadequate and impose high costs when things do not go in a predictable fashion. In the software business, probably the only predictable things are the frequency of requirements changes and the immaturity of new technologies! In many cases, managers try to impose predictability by going in for rigorous methodologies that impose a set of linear processes that need to be done to meet schedules and dates. To handle new and uncertain technology, they put a premium on recruiting and measuring team members on technical skills that become out of date rapidly. Less attention is paid to training and soft skills improvement such as project planning, estimation, scheduling, risk identification and management, and so on. Many team members are very committed and hard working but, because they have never been trained in these skills, it becomes very hard for them to provide good estimates, suggest better solutions, or identify real risks.
It is no wonder that many folks get into trouble with their managers when tasks take much longer than expected. “What! You originally said it would take a week. Now you say it may take another couple of weeks!” Countless poor souls have worked many long hours to meet deadlines based on unrealistic estimates. All this stress on team members and managers alike (managers too suffer from stress!) does terrible things to team morale and communication. Sometimes folks run so short of time that they are unwilling to even give the time of the day to their team members! People become intolerant of others’ mistakes because it will have a negative impact on their deadlines.
Another area that many organizations are weak in is in management systems. Although many project methodologies impose rigorous management processes in place, it does not necessarily mean they are good! In many cases, they are very weak at identifying changing risks and other issues. Changing requirements or designs are not very well handled because they produce big changes to project plans. These plans are frequently based upon tasks that have been defined and estimated much earlier when many items were not well understood. So, the introduction of new tasks and the replacement of old tasks makes the project have no resemblance to the original plan on which many deadlines and metrics are based.
A New Methodology for Defining Requirements
It is no wonder that we are starting to see a lot of interest in new “agile methods” that include methods such as eXtreme Programming, SCRUM, Feature Driven Development, and so on. These “agile methods” promise to handle fluid and unclear requirements better than traditional methodologies. Quick and frequent releases of working software help uncover problems with new technologies before too much of an investment is made. It also enables workarounds to be explored in case of problems with technology. Many project team members also like the increased responsibility and control that they get. Team members are no longer cogs in the wheel but crucial players.
Managers usually have been more skeptical. I know I was when I first heard about these methods! However, they do work but also require attention to issues such as team skills, customizing processes to their needs, and management reporting and control systems. Team skills need to be enhanced in terms of using agile methods as well as in the areas of estimation, planning, and risk management. I cannot stress how important this is because bad estimation, planning, and risk management can still cause projects to fail or be delayed. Software definition, development, and delivery processes need to be reviewed and customized so that agile methods can be used successfully. Each organization is different and has different needs. Unless the processes and methods you decide to use fit your needs they can be as painful as an ill-fitting shoe.
Lastly, management reporting and control systems need to be reviewed and enhanced to work with these new methods. The traditional management control systems cannot effectively monitor and check the progress of projects done using agile methods.
Conclusion
Software project management is not always as easy as it looks! Traditional project management techniques are unable to adapt to changes and new risks very well. This makes it harder for teams to be flexible and react quickly to changing project issues. However, new techniques such as agile methods can make project managers and their teams’ lives easier (and happier!) when properly implemented. A skilled and committed team will deliver better software faster and cheaper.
Copyright © 2002 Sanjay Murthi
Author Information:Sanjay Murthi is President of SMGlobal Inc. He has over fourteen years of experience in the software industry in a variety of roles and responsibilities. He now helps companies review and improve their software definition, development, and delivery process. He can be contacted at smurthi@smglobal.com. |
|
