The resigned acceptance by developers that a majority of their time will be spent in rework could be the biggest indicator that projects are not set up to succeed from the start. Without a clear and shared vision, it is inevitable that developers will need to build and rebuild which increases the project budget and extends the timeline.
80% of developers admit that at least half of their time is consumed by rework.
46% of developers state they are unsure of the details the business needs them to achieve with their project.
For a project to end on-time, on-task, and on-budget, rework needs to be minimized. To prevent rework, all team members need to understand the main causes of scope creep and rework and have strategies to avoid causing the extra work.
Strategies include providing access and openness for the types of communication that will prevent members from making individual decisions that conflict with the best choices for the success of the project.
Ask Before You Act
What is scope creep? When decisions made by any member of the project team add extra work to the project, the scope increases or creeps. Sometimes the simplest decision can increase scope and derail a project.
Let’s look at an example. On a project, a developer thought having icons wiggle side to side when the mouse hovers over them would be a good addition. It was not in the requirements to have a wiggle, but it was also not in the requirements to not wiggle. The developer took 15 minutes to add the wiggle functionality. It worked, so the quality analyst sent it on to the business for user acceptance testing. When the business team member tested the page, they were surprised to find a wiggle and did not like it. The next meeting included a discussion of the wiggle and it was decided to remove the wiggle. The code went back to the developer and it was removed. It was then retested by quality and business.
The original 15 minutes of work ultimately added 4 hours of work to the project. If the developer had taken 5 minutes to ask if the business would like the wiggle added, the scope would not have increased and the developer would not have ended up recording the page. During a project, hundreds of decisions are made opening the potential for good-intentioned choices to increase scope and cause rework.
Teams with a strong culture of communication and consistent business involvement will have less “wiggles” in the project. Create a team norm of ask before you act to keep your project on the road to success.
In essense;
The majority of people believe that IT and business both begin and end out of sync. Much of the inability to align on completion surrounds the understanding of bugs. A bug is any flaw in a software system, but who decides if it is a true flaw or a choice?
Most IT teams define bugs as critical, high, medium, and low with the level tied to the coding effort it will take to fix the bug. An item that will impact the entire system stopping it from working correctly will be a critical where a typo will be a low.
Business teams define issues by how they impact the customer or user. Agreement that an item that stops the system from working is critical is easy to accept; however, typos are rarely low to a business member. They may be easy to fix, but they are embarrassing to the business.
There will be a set of bugs that are a matter of choice. For example, if the user hits save and the page saves and takes the user to a dashboard page, this was a business choice made in requirements. If during testing, business decides they would rather have the user directed to another page, it would be logged in as a bug that could be low to high depending on the amount of occurrences and the effort.
Bugs that do not stop functionality need to be decided on very intentionally. Where the business may want the page change if it is 15 minutes of effort, they may not want to spend 4 hours on the change at this time. Teams with agreement on bug classifications will be likely to agree a project is truly done.