Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
Generally, an IT project schedule is divided into three phases: 30 percent requirements, 40 percent coding and 30 percent testing. But have you ever noticed that in the coding phase, 60 percent of the effort goes into unplanned bug fixing?
I read somewhere that in the software industry, 90 percent of the tasks take 10 percent of the time, while the other 10 percent take 90 percent of the time due to rework. If as a project manager you can control this rework effort, I am sure that your project will be successful in terms of profit value, customer satisfaction and team motivation.
The project I am currently working on is no different. We had the same rework problem. So based upon data analysis from the last 4 to 5 months, the team came up with a list of preventive actions that will help us in reducing rework.
But I was still looking for something to keep them motivated to avoid rework. I prepared a logo and it was pasted on all desks.
It would help those who believe that it would help them! Team members' buy-in is required.
Of course someone has to remind everyone to keep looking at it regularly.
I like your logo and the slogan. If I understand your question correctly, I would do the tasks below to avoid software rework:
1. Understand the real requirement and document in clear and concise language
2. Review requirement with the person(s) responsible to sign-off the software and get approval after review
3. Translate requirement to functional specification and document functional specification in clear and concise language
3. Review functional specification with business analyst, solution architect, and development leader to make sure the functional specification matched all requirement
4. Repeat step 1 - 3, until no ambiguity and all requirements are mapped and realised in functional specification
5. Implement/develop software as what have been defined in functional specification document
In addition to the 5 points above, I would also monitor software quality, make good test plan and test cases, and control changes properly.
I would appreciate you for sharing your points regarding the same subject.
I agree with you half way. Rework should be better controlled, but never ever should you try to prevent it, as your logo suggests.
Rework happens for a reason. It is necessary and a integral part of software development. The underlying hypothesis is that you cannot get it right the first time. You need to build it once and than enhance or rebuild it over and over again based on experiences and reactions to your earlier attempts.
The approach to control rework should be the opposite. Embrace rework. Accept that it will happen and plan several rework cycles. Don't prepare a task forever in fear you could miss something. There is no good in spending plenty of time trying to get right the first time and than have to rework anyway. Just do and know you can correct actions during the planned rework. You will be faster this way.
This isn't new practice. "Rework" is a corner stone of many common project management and software engineering methods: PDCA-cycles, agile methods, extreme programming, scrum etc.
Very practical issue.
But, I am not consent with the statistics - 60% of unplanned bug fixes. This is way too much, you should seriously question your development.
The Wiki definition of "software bug" is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.
As per my experience, it is not the bugs which take most the energy, but it is the changing requirements or designs end up rework. More emphasis you give on the requirements and design followed by good change management will lead to less rework. The best but difficult way to handle this is provide time and resources for alteast 20% change in additional to other risk management slack.
I would recommend immediately going around and removing the signs from everyone's desk. Not only are the signs not going to help, they may very well make the situation worse.
It looks like the team made a good first attempt by identifying specific approaches that might help reduce the level of "rework." Why not continue to track the team's progress and determine which corrective actions might actually be productive and which are not effective? Why not do further analysis as to what constitutes "defects" and "rework"?
In software development, the terms "bug" and "defect" are quite subjective. In my experience, issues uncovered in test are rarely the result of a developer having done something wrong. In most cases, the issues are a result of an omission - correction of an omission can hardly be viewed as â€œrework.â€
For a more extensive discussion, please refer to â€œOut of the Crisisâ€ by Dr. W. E. Deming. From pages 65 â€“ 67, â€œEliminate targets, slogans, exhortations, posters, for the work force that urge them to increase productivity. â€¦ What is wrong with posters and exhortations? They are directed at the wrong people. They arise from managementâ€™s supposition that the production worker could, by putting their backs into the job, accomplish zero defects, improve quality, improve productivity, and all else that is desirable. â€¦ Exhortations and posters generate frustration and resentment. They advertise to the production worker that the management are unaware of the barriers to pride of workmanship. â€¦ The immediate effect of a campaign of posters, exhortations, and pledges may well be some fleeting improvement of quality and productivity, the effect of elimination of some obvious special causes. In time, improvement ceases or even reverses. The campaign is eventually recognized as a hoax.â€
Process improvement is a difficult task and, as Dr. Deming forcefully indicates, it is not helped by the use of simplistic posters.
Specially in IT projects, "Do it correctly first time" has a good number of points to be considered, a better requirement understanding, and expertise on the business should reduce the number of issues.
Anyway, the test phase should be carrefully performed, in order to identify all the issues before to delivery the solution to the client.
Thanks for sharing
How are you justifying the variance it is causing?
A logo pasted on my desk ... I am little skeptical about the success ... as someone 'buy-in' and 'governance' is needed
Here is something that I would have done ...
1) Analyze the skills of my resources (Developers/BAs) and look for some advanced traning ..smart allocation for tasks
2) Baseline your requirements
3) and lastly hold the people accountable for that rework if it is not planning/requirement then what is it? and look for the Whys?
My opinion about the Logo:
1. Firstly, the team members have to be explained about the project rework and its impact. Every team member have to be made accountable for their respective code/application.
2. Rework logo can be made available during the beginning of the each phase for one/two days as the screen saver/poster on the computer instead of having the hard copy pasted on the desk.
Points to mitigate the Rework:
1. The most important and critical is requirements phase.The requirements need to be more clear and the sign-offs have to be taken from the customer.
2. Prototypes may be prepared and shown to the customer for his comments and may be minor changes can be accepted at this level.
3. Good test plans have to be created.
4. User acceptance test need to be carried out before the deployment of the application.
5. Code review by the experts have to be carried out so that performance and other related problems will not arise even though application might be working.
6. Motivation levels in the team members have to be maintained at high.
The biggest culprit of "rework" tends to come from not enough requirements capture, changing requirements or customer sign-offs were not taken.
Everyone else commenting did a great job at describing steps to limit rework, but I agree you must have the full team buy-in. I find 60% of coding doing "rework" may be high. If it is that high, there may be other problems than just the coding process.
When it comes to software development, "rework" is the name of the game. It is so because the end result is achieved by closer and closer approximations to desired state. It is creative work that cannot be planned in such a detail and executed so precisely that no modifications are necessary. Imposing "no re-work" rule to software development team is like asking a novelist to write a bestseller in pre-scheduled time, in one shot, no revisions, no modifications...
So, "rework" is the most natural thing in software development and instead of trying to restrict it, I would suggest you better embrace it. Think agile methodologies (Scrum, etc.) as opposed to traditional ones (Waterfall).
Why not have actual discussions about the project goals, challenges and resources beforehand?
Why not have regular meetings or at least check ins where everyone needs to meet a goal, rather than placing the project as a whole in front of them?
Pasting a logo with a giant X on it blaring at the to DO NOT DO isn't exactly motivating. In fact, it's pretty passive aggressive.
If you want to provide motivation you'll need to make more of an effort to get communication rolling and the information out.
You've got the right idea about cutting down on "rework" however you'll probably never be able to get it down to zero. It'll be better all around to have communication, leadership and information.
I'm a QA Lead not a Project Manager. I wouldn't define "un-planned bug fixes" as re-work. It's just work.
What leads to that last minute un-scheduled extra time is scope creep and dates missed in my experience. Drop dead dates for final design, requirements, and development need to be met. As soon as they are not then a mitigation strategy that includes QA needs to be worked out.
It's my job as a QA Lead to tell the Project Manager the impact of a missed date or a change in requirements, design or development. Usually I can absorb the changes without impact to the schedule but there are times when the Testing Period will have to be extended in response.
If you are losing time to un-planned bug fixes at the end of your projects, I would suggest working closer with your QA Lead. Make sure they are involved at the start of the project and sit in on status meetings even if the testing period is months away. The earlier they know about changes the earlier they can adjust their schedule to mitigate the risk or let you know of a possible change to the schedule.
Even though I am a QA Lead, most of what I do can be termed Project Management. In fact I have MS Project open right now in order to plan out in detail each testing task.
I work closely with my PM's on matters of resourcing, scheduling and risk management. However, since my part of the project is at the end, I am dependent on my PM and other Team Leads to make their dates. Every missed date makes the time my team actually gets to test that much shorter. It's very common for dates to be missed which results in a shorter testing window which either leads to a poor quality project or "un-planned bug fixing" time.
To sum up, if you are having problems with "un-planned bug fixes" empower your QA Lead to help you reduce that time and risk. Get them in early, keep them informed and understand their needs and impact. A good QA Lead may not be as cost effective as a logo but we can really help a Project Manager look good if given half a chance.
I'm sorry if this sounds negative or self serving but it's an area that I felt I could contribute to given the audience.