Who Makes the Decisions to Cut Corners?...

We produce SAS code to solve business problems, right? Those business problems might be a simple question about recent sales figures (resolved by a quick ad-hoc report), or they might be allied to the ability to predict manufacturing failures so proactive action can be taken to avoid the failures. Either way, there's a business benefit which has a value attached, and usually there's a timeliness associated with it too.

For any significant piece of work, you will have some kind of plan as to how you will deliver the work; and that plan will include some element of each of the following standard steps (plus effort estimates for each):

• Requirements capture
• Design
• Build
• Test
• Deploy

Sometimes (often?!) the time and cost constraints come into conflict with the total effort indicated by the plan. In other words, the project manager says "you'll have to deliver sooner than the plan indicates, we don't have enough time/money (delete as appropriate) to do all of that". How do you resolve this apparent conflict?
All too often the developers reluctantly agree to do less testing or provide less documentation, but are the developers (or project manager) the right people to make these decisions? In cases where there is no project manager, the sponsor/customer will often leave the decision to the development team.

Any software development team that operates in something better than chaos will have a template for how they go about their work, i.e. they will have a skeleton project plan that:

• itemises the products of the development work, e.g. design specification, unit specifications, build log, code, operations manual, user guide, developer testing report, peer review report, etc
• identifies the benefits of each product and the impact of not producing them
• allows estimation of the relative effort for each task
• can be provided to any project manager (or customer) who commissions some new development work from the development team

If anything is to be taken out of the plan (or reduced in size), there will be an impact; and the sponsor/customer of the project will be able to see that impact (and its associated cost). For example, if peer review or developer testing is reduced, the number of bugs observed during system testing will increase, causing system testing to take longer. In addition, if there are more bugs being passed into system test, there will be an inevitable increase in the number of bugs that sneak through without being spotted. The result is a less stable production system which requires greater support once operational. This result is visible to the sponsor/customer of the project and will cost money.

So, who should make the decision to reduce or remove development steps from the process? It certainly shouldn't be the developers in isolation. The developers can offer options to the project manager, but they shouldn't make decisions, i.e. they should be consulted, but they should be considered responsible for making the decisions. Perhaps the project manager is sufficiently empowered to make the decision, but if it's going to have a significant impact on what is being delivered, shouldn't the project manager involve the sponsor/customer in the decision-making process? After all, the sponsor/customer is doubtless expecting a system that meets her functional requirements, but she'll also be expecting a system that is reliable, robust and can be used on a day-to-day basis without requiring a huge army of operations and support staff. If the team is not going to deliver what the sponsor/customer expects, the sponsor/customer should be told and should be involved in the decisions about how the circle can be squared: it's the age-old issue of the relationship between scope, cost, time and human resources.

Of course, none of this is possible if the development team don't have a repeatable process that is encapsulated in a skeleton project plan with clear definitions of the products of each step (and their benefits, and impact of losing them). If your team doesn't already work to this level, you should have a good think about how you manage the inevitable trade-offs between scope, cost, time and human resources. Is the right information being given to the right people in order to make the right decisions?