Voices on Project Management

> Back to Voices Home

No Project Rework

| | Comments (12) | TrackBacks (0)
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.

sanjaypost1.png 

What do you say, is it going to help us?

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: No Project Rework.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/326

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

12 Comments

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.

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.

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).

Stan

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.

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.

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?

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.

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.

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 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.

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.

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.
;-) :-)

About This Blog

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.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll