Project Management Issues

The customer has approached the project management with a request to finish the project earlier than originally planned. The customer is willing to put some additional money into the project, which can be used to add more developers. The hope of the customer is that with more money, we can add more people to the project and thereby complete it earlier.

The customer's assumption might be valid if the project were at the very beginning. But the project is already three-fourths completed, so adding more people might not let us finish earlier. Not only would the new people have to learn about the project and the domain, but also they would take time away from the current developers to get up to speed. Thus, adding more people at this point would most likely result in the project's being released even later than originally planned. The flaw in the customer's assumption can be compared to the idea that if one woman can have a baby in nine months, then nine women could have a baby in one month.

For this reason we turn down the request of the customer at this point in the project. Instead, the project team suggests other scenarios in which the project can be delivered earlier than scheduled.

10.4.1 Relation of Project Scope, Cost, Quality, and Time

Classic project management defines three variables (cost, schedule, and project scope) that are dependent on each other. For any two of the variables, the third one is given and cannot be chosen. In software development, sometimes we define one additional variable: the quality of the product. The following list shows the four project management variables for software development.

• Scope: The scope of a project is defined by the deliverable features.
• Schedule: The schedule is defined by time needed to complete the project.
• Quality: The quality of the project is defined by the amount of testing, code reviews, and other quality assurance activities performed.
• Cost: The cost of the project is equivalent to the expenses the project has. This includes the cost of the people working on the project.

Figure 10.7 shows the classic project management variables and the four variables of software development project management.

Figure 10.7. Project Management Variables

For any three given variables in software development, the fourth variable is already set. This means, for example, for a given scope, schedule, and quality, the cost is not variable but is given through the other three variables. This means that the customer can set at most three of the four variables, and the project team delivers the other variable based on the three chosen by the customer.

In addition, note that the cost factor can be adjusted only within limits. As mentioned before, adding people (which would be a cost) at the end of a project will not result in the expected earlier release of the project. On the other hand, if we want to finish the project earlier than scheduled, we could decrease the scope or lower the quality. Both actions would decrease the time we need to finish the product.

10.4.2 Early Delivery Possibilities

With the knowledge of the four variables, we can now prepare some proposals for resolving the customer request for early delivery of the project.

Reduced Quality (Resolution Proposal 1)

The project can be delivered with less quality. This means that the transition phase will be cut short, and testing will not be as extensive as planned.

Reduced Scope (Resolution Proposal 2)

Some features will be cut. The application will be delivered with fewer features than originally planned, but the transition phase and testing of the implemented features will be done as planned.

Release as Planned (Resolution Proposal 3)

This is the preferred option. The project will be delivered as planned. All the features will be implemented, and testing will be done as planned. The advantage of this proposal is that all basic features will be available (remember that we have already delayed implementation of certain advanced features to a future release, as noted on the defect tracking sheet), and the application will be delivered with sound quality because testing will be done extensively in the transition phase.

After review of the resolution proposals, the customer agrees that the best solution is to deliver the product as planned. It would not make sense to deliver an insufficiently tested application to the users and would incur the risk of our customer losing business because of avoidable defects in the software. Also, the customer agrees that all features that were planned for in the first release are basic features that must be provided. Therefore, the project is to be delivered as planned, with the features as planned.

10.4.3 Other Actions

The posted project plan shows that the project is still in accordance with the plan. No problems are reported that would make new planning necessary.

In the final phase of the development, stand-up meetings are introduced. These short meetings are held every other morning for the remainder of the project. During the stand-up meeting, all participants are standing and everyone gives an update on the status of current work. This type of meeting is supposed to last no longer than 12 minutes, and the purpose is to increase communication of status and problems within the project team. The identified problems usually are not solved in the stand-up meeting, in which case we schedule follow-up meetings with only the relevant project team members.

Stand-up meetings are conducted to get an update from the team members every other day (without taking too much of everybody's productive time), to increase communication among team members, increase visibility to all parties involved, and to have some coffee.