Software Development
Developing software can be an unforgiving experience, especially if you disregard basic facts.
Scientific management
There is a belief that software projects are best organised according to the principles embraced by the manufacturing industry. This is understandable, since application of Taylor’s scientific management principles from 1881 has given unmatched profits and quality gains in mass production of standard products.
Besides the fact that a software project is seldom manufacturing the same product over and over again, there is a misconception about what is really done in a software project.
When the “product” you are building is knowledge rather than a toaster, task specialisation is not a good idea. We all know how difficult it is to transfer knowledge from one person to the other. In fact, knowledge and understanding is something you construct, not something you can transfer between brains. It doesn’t matter how many documents you write. Therefore, the number of handovers should be kept as low as possible in a project. Your project should be organised with the building of knowledge in the centre. The “task to build” is vastly less important than the “task to understand”. Most projects, however, still believes that the build activities are the most important ones, therefore it is these activities that should be rationalised and standardised.
Separation of planning from operations is also not a good idea. Commitment to plans is fundamental to projects, and if you are responsible for planning your own work, you probably are more committed to make them work.
Quality standards, such as ISO 9001, have a certain influence from scientific management. An example of this is the belief that you can define responsibilities and authorities of a role in a document. We all know this is impossible to do, but for the most simple roles. If you don’t believe it, try and describe your responsibilities as a parent! The best role description you can have is actually the process description. Roles are defined by their activities, not the other way around. If you have meetings with your customer and write requirements in a Requirements Specification, you probably have the role of a Requirements Engineer. Activities are much more important than roles.
Where do you spend your time?
When we work in projects we want to create value for our customer. For different reasons we need to create value for our own organisation and for our selves as well. But creating customer value is the only thing that pays our salary at the end of the month.
It is a sensible thing to spend your valuable time at those activities that creates most customer value. So where do you spend your time?
If you have a project meeting for two hours each week with all your project members, you spend five percent of your time budget on this activity. This is a lot of time, since the Requirements Engineering work typically takes 10% of the same budget.
Many Project Managers want project members to record spent time according to the implementation of different functionality, for example: working with functionality A, working with functionality B etc. If you never are going to develop the same functionality again, this data can hardly be used to plan a new project. It can be used for follow-up, but it cannot be used for planning.
Better is to record time according to general project activities, for example:
-
•Project Management
-
•Configuration Management
-
•Quality Assurance
-
•Requirements Engineering
-
•Design
-
•Implementation
-
•Test Engineering
Okay, so now I know I have spent 1500 hours on Project Management and 1200 on Requirements Engineering, what good is that? Absolute numbers are not important, because they vary between projects, but relations between activities are important. If you calculate the hours for each activity, you may notice that you spend 20% of your time on Testing, 30% on Implementation, 10% on Design etc. This may help you plan your next project. Also, it puts a question to you: where do you want to spend your valuable time? If you spend 30% on Project Management and 30% on Testing you probably need to think through how you manage your projects.
Projects that are less mature spend a greater deal of their time in the later phases, typically 30% on Testing and maybe as much as 40% on Implementation. Projects that are more mature tend to spend more hours in the early phases, i.e. Requirements Engineering and Design. These projects know that their success depends on the quality of work accomplished in these phases.
Quality or quantity?
The plain fact about dealing with people in projects is: quality always beat quantity. If an experienced programmer solves a problem in one or two days, a mediocre programmer needs between one and two weeks to do the same work. Moreover, the number of failures after delivery is much less for the experienced programmer.
However, as a Project Manager, you seldom have the choice between quality and quantity. You have to deal with what you get, which is a sad fact.
Management or Processes?
For historical reasons, project models emphasise resource management and task scheduling. One problem with task scheduling is that the defined tasks tend to be oriented towards the functionality of the product – for example: implement the WFE unit - and you normally do such tasks only ones. The predictability gets very low in such circumstances. In fact, defining a product through task scheduling can never be as good as defining it by a Requirements Specification. The RS is in every respect superior to any Work Breakdowns Structure (WBS), but the RS is strictly limited to describing the product. In a project, you need to do a lot of other activities that are not product related. In this sense, there is a need for a WBS, but with another focus. On the other hand, if you can define your project activities in a way, so they can be performed in more than one project, you have a process at hand. And processes are always nice, because they can be taught, measured and improved. People still debates if they are repeatable in an uncontrollable environment, but that is probably less important for achieving a desirable result.
The good news is that you, as a Project Manager, only need to implement three key processes in your project. You have probably guessed that Requirements Engineering is one of them, but you need Test Engineering and Configuration Management as well. Test is the other side of the coin. The Test process ties everything together; it’s the process that demonstrates that you have fulfilled all product requirements. Configuration Management is the organiser, the process that in a simple way tells you the status of your product. Surprisingly, Project Management is not one of these three key processes. You probably decide that you need it anyway, because project sponsors like to be informed about the status of your activities and how much of their money you have spent.
People learn processes by executing them. It is very rare that someone learns a process by reading the process description. It can happen, if people are very experienced. Otherwise, if you expect your process to be executed in a project, you have to show people hands on how it’s supposed to work. First, you have to do it, and then they have to do it.
Tools
Tools are often used as simple solutions to complex problems. As such, they will accomplish very little for you. Tools should be used to support a sound process, not the other way around. Most tools have, however, a built in process that you, as a user, are supposed to follow. If this built in process doesn’t comply with your own process, you will be in trouble. A really good tool, on the other hand, can be adapted to support your process, which is the way it should be.
When it comes to Requirements Engineering, a sound process is much more important than a tool. You don’t have to store your requirements in a database: you can store them in a document, together with their properties and all other information. It just takes some effort. What you do need is a good word processor, which enables you to share your information on electronic format.
