When is Complete Complete?

Developing software is complex but breaking the problem down into smaller tasks makes the job easier. It is OK if you are the person who defines the work, splits it down and then completes it yourself as you fully understand what the problem is and when the problem is solved. This is not normally the way it works in the real world. Here the problem is defined by the customer; there is generally someone or a layer or people defining what needs to be done to solve the problem and then a group of developers who are actually implementing the solution. Once the problem and its solution are split between different people the concept of complete starts to become an issue. There are three points of view of completed:  Developers’ perspective, Team Leaders’ perspective, Customers’ perspective.

The customers perspective of completed is when the customer gets what they want. This is not necessarily what is in the requirements. One of the biggest problems with requirements is that the person or people who normally write them understand what they want and often assume that something will be like what they want without actually specifying what it is they actually want. These are hidden or implicit requirements.

The team leaders’ perspective of completeness is when the developers have told the team leader that the task is completed and the software has been built, deployed and is in a fit state to test or demonstrate.

The developers’ perspective dictates that something is complete when the item of work given to the developer is completed as close to the specified design as possible. If you are lucky the developer has let the team leader know which parts of the design have not been implemented for whatever reason.

These three perspectives often are not compatible with each other which lead to disappointment with the customer as things do not appear to be going to plan even though the developers and team leaders think things are going well. If you are not careful this could lead to a de-motivated workforce and an even more disappointed customer.

One of the secrets of a successful development is to align the three perspectives of completion. This generally lies with the team leaders or project managers. This layer of the development process, interfaces with both the customers and the developers and it is their actions that ultimately determine how successful the project is. For simplicity we shall assume that the team leader is handling this issue. It could easily be anyone of the senior members of the development team: the consultant, designer, project manager, team leader etc. It is the team leaders’ responsibility to fully understand what is actually expected to be delivered to the customer. If the team leader does not fully understand what is required then how can anyone expect to get what they want? The team leader must rely on fact and not hearsay or rumours. The team leader must understand the requirements and try to work out what the implicit requirements are and handle the delivery expectations of the customer. If there are features that the customer seems to be talking about that are not explicitly specified in the requirements then the team leader needs to get to grips with what the customer is expecting to be delivered. This will often contradict with what the development team has been contracted to do. This may require that the project manager needs to ensure that the scope of the project is managed and that additional work is charged accordingly (assuming that the customer and developers work for different organisations). It is the team leaders’ responsibility to make sure that the customer is aware of what is being delivered at each stage.

Once the team leader has aligned the customers’ expectations with the requirements the development team can now work to complete the tasks. To make sure that the team understands what they are expected to deliver the team leader must specify the minimum criteria for completeness. This is effectively a set of tasks which explicitly defines what needs to be done. This will include testing, preparing for a demo (including what features are required to demo) and building and deploying. The goal of the team needs to be specified so that all the development team understands what is expected from them. The team needs to be made responsible for delivering the demonstration and the whole team needs to be involved with its preparation. This means that whilst the demonstration is being prepared and the software is being built and deployed, any problems are resolved as soon as possible by the development team. In addition to this any short fall in specification needs to be identified as early as possible so that the customer can be notified and/or the problem resolved before the item is delivered as complete. It is the team leaders’ responsibility to ensure that all this happens, if the delivery is not successful then is it not acceptable for the team leader to blame any member of the team. They are ultimately responsible for the successful delivery.

Aligning the perspective of completeness of the customer, team leader and developer is one of the key to successful software developments. The team leader is the catalyst for this alignment and needs to be able to communicate effectively with the customer and the developer; to understand what is required and to communicate this to the development team.