The issue of feature creep, where additional feature requests are added over time, is common to the majority of software projects. For developers who don't have a huge amount of experience in managing software projects, it becomes very easy to let feature creep get out of control by not realizing what is happening and/or being too polite to the customer. Feature creep becomes a serious issue where:
- The client is paying a fixed price for the work, meaning that additional features are outside the scope of the project's price quote and therefore means you are giving free labor.
- A completion deadline is part of the agreement, especially where there is a bonus involved or where the client has grounds to take legal action for late delivery on the basis of damage to the client's business.
There are many reasons why feature creep occurs on software projects, and knowing their cause allows you to identify the most appropriate actions to resolve them as they occur. The following are common factors for feature creep that you are likely to experience in your freelance and contract projects:
- Assumptions of the original agreement - In most cases where this occurs, it is simply a misunderstanding between the software developer and the client regarding the scope for detail and complexity that a feature in the specification has meant to represent. Regardless of how innocent this may be, the issue can cause friction in the project that leads to the software developer losing out financially and lost trust from the client. The following are steps that can be taken to avoid this type of issue from occurring:
- Word details in written agreements and specifications to explain the level of detail for functionality of every feature to a point where it can't be argued that undisclosed requirements are classed as being defined under ambiguous wording in the agreement.
- Rather than specifying what functionality isn't covered, look to word details to be specific on what is covered and restricting the specification and agreement to only cover the scope of what has been written.
- Make use of lean software development principles to reduce the scope of the project to the minimum viable product - only the functionality essential for the software to be useful for its purpose - Not only does this reduce the risk of extra functionality causing problems based on assumptions, it allows the client to have a working version faster at less expense.
- Changing business environment - Successful businesses are a product of how they react to the demands of their environment, whether it is sales driven by through changing demands of buyers, changing legislation or emerging threats from competitors. All of these factors affect the requirements for your software, and the longer the development cycle, the higher the chances are that something will happen in the business environment that results in changes/additions being requested. Although change often can't be avoided, the following actions can be taken throughout the project to anticipate and manage it:
- Use robust software development patterns that allow for changes and additions to be embraced efficiently—see Chapter 10, Software Development Methodology.
- Use a lightweight software development methodology that provides flexibility for change, as opposed to a heavyweight methodology that contains too much planning to allow fast reaction to changing needs halfway through the project—see Chapter 9, Software Development Resources, Patterns and Strategies.
- Consider using short release cycles and lean development principles to reduce the risk of business environment changes making software functionality redundant—this is covered in more detail later in this chapter.
- Committee politics - Where there are multiple stakeholders involved in a project, committee politics can become an issue where too many people ask for too many features, and where everyone is pressuring you to put their feature as top priority. This can be avoided by:
- Identifying the primary decision maker and having them provide you with development requests that have been fully vetted to their satisfaction—a single point of contact who relieves you of being directly involved in their organization's politics.
- A well defined project specification and written agreement created before the commencement of any programming, making the level of detail clear of what is to be developed and the procedures and time/price implications of change requests.
- Hyping client expectations - When communicating with clients about the software project, be careful not to unnecessarily increase their expectations. Extra care should be given to how features and possibilities are described, as well as any imagery shown. Avoid being optimistic about what is possible, whether in terms of timescale or technical achievability. Where there is scope for the client to assume more advanced features that have been agreed, extra effort should be made to define any limitations on the features to be developed in both the project specification and written agreements signed by both parties.
- Assumptions of user needs - People who have no background in software projects are often tempted to cram as much into their requirements in the belief that more is better and that it makes their software product/service more appealing to a wider audience. This type of approach leads to new additions being requested after the initial agreement, with these extras often being described as part of existing features. This problem comes from two factors; the client not being experienced in dealing with software projects, and also not fully understanding what they want from the start. When faced with this scenario, extra care needs to be taken to educate the client about the impact of trying to cram too much into their design—i.e. additional features increase the time to market and the risk of investing in features that don't get used. By educating the client about software release cycles (see later in this chapter), you can persuade the client to separate non-urgent features that can be revisited after completion of the main system.
Clients often don't fully understand the problem they are trying to solve with the software project they are hiring you to develop, meaning they will realize the need to add or refine features. Like with other reasons for changes and additions to the specification, this introduces an additional time requirement and therefore needs to be covered by the available budget. This issue can be avoided by:
- Use of prototyping before commencing development of real code. This provides the benefit of allowing the client to see how the final version would function and the ability to request changes and additions before commencement of code production. A significant cost advantage can be gained by avoiding the need to undo code, which can be timely to review, alter and test – hence it being expensive.
- Getting the client to focus on the releasing just one component at a time. This helps both you and the client to understand how the functionality should work in more detail, resulting in a better functioning result to address the problem the software is designed to solve.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.