Get it right the first time. Ok, I guess I just gave away the premise of this article. It goes without saying that everyone hates rework…right? I know I do. It’s a waste of my time…makes me look bad – even if it’s a result of something a project team member did or my customer changed their mind on. It still makes me and my project look bad. And not to mention the impact on the budget. Wow…rework is costly. Sometimes very, very costly. And it’s time-consuming, counter-productive, annoying, degredating, boring, frustrating, and costly…did I already mention costly? Very costly.
As the project manager you’re combating timeline issues, budget issues, customer satisfaction issues, and resource engagement issues. There is definitely a lot at stake and you can’t afford to lose the forward momentum that rework is famous for killing.
So let’s avoid it. How? How do we position ourselves and our teams on a project to avoid rework? What planning measures can we take, what actions can we utilize and what processes can we incorporate to help ensure that our projects don’t fall victim rework?
Main causes of rework
In my opinion…and experience…these are the top four reasons we end up performing rework on our projects in the first place…
So now that we know some of the main causes of rework on our projects, let’s look at some of the best practices that we can use to help us and our teams – and our customers – work in the best interests of project success to try to avoid rework.
Make enough time to document detailed requirements. Requirements are the lifeblood of the project. As the project manager, ensure that you have allowed enough time in the project timeline to properly capture and understand project requirements. Confusing, vague, incomplete, or missing requirements lead to rework later in the project as you and your team work to fix whatever went wrong during requirements definition. Because if requirements are not documented properly, you’ll likely end up delivering a solution that your customer doesn’t want or can’t fully utilize. Get it right the first time on requirements to avoid unnecessary rework.
Always communicate effectively. Always practice effective and efficient communication. And I don’t mean overcommunicate – that can cause it’s own problems. Your team will stop listening to what you say and stop reading what you send if you send too much useless information. And everyone will stop attending your meetings if they don’t convey meaningful information.
Use project management templates to create meaningful reports, notes, and schedules to distribute to your team and customer. Make sure your project status reports are informative and timely. Keep your project schedule revised and in everyone’s hands. Distribute status notes in a timely manner. All these things serve to better inform your team and your customer. And a well-informed team knows what they should be working on and they are usually working on the right tasks at the right time – greatly reducing the potential need for rework.
Monitor resource usage closely and forecast accurately. A revolving project team can often lead to rework as understanding of tasks gets confused and because different people do things differently. Bringing in a new tech lead mid-way through development can lead to inefficiencies in the development process which can often result in rework later on. Keep your resource forecast accurate and up to date so that you can keep them engaged on your project when you need them and so that you don’t lose them to other projects.
Have the customer plan and prepare for testing well in advance. Test cases and test scenarios need to be created and owned by the project customer. Have them prepare for testing in advance by taking ownership for these tasks. And have them start this process very early in the project. It will help the act of user acceptance testing go much more smoothly. Plus, if they know what they want to be testing for it will keep them from shooting from the hip during testing – a process that can often lead to misinterpreting results and causing unnecessary rework for your development team.
Summary
Rework happens. It happens on nearly every single project. That’s why it’s crazy to plan your project budget so close to the bone that there’s no room for any small amount of rework. But small rework issues should not bring down the project – and they just don’t. It’s the big rework issues that kill the budget, upset the customer, frustrate the team and upper management, and bring a project to a screeching halt. That’s what we’re trying to avoid like the plague…that’s what these processes should help to eliminate.
As the project manager you’re combating timeline issues, budget issues, customer satisfaction issues, and resource engagement issues. There is definitely a lot at stake and you can’t afford to lose the forward momentum that rework is famous for killing.
So let’s avoid it. How? How do we position ourselves and our teams on a project to avoid rework? What planning measures can we take, what actions can we utilize and what processes can we incorporate to help ensure that our projects don’t fall victim rework?
Main causes of rework
In my opinion…and experience…these are the top four reasons we end up performing rework on our projects in the first place…
- Misinformed project team members
- Requirements that aren’t complete
- Poor communication overall
- Turnover of project team members – on either side
- Incomplete or inadequate testing
So now that we know some of the main causes of rework on our projects, let’s look at some of the best practices that we can use to help us and our teams – and our customers – work in the best interests of project success to try to avoid rework.
Make enough time to document detailed requirements. Requirements are the lifeblood of the project. As the project manager, ensure that you have allowed enough time in the project timeline to properly capture and understand project requirements. Confusing, vague, incomplete, or missing requirements lead to rework later in the project as you and your team work to fix whatever went wrong during requirements definition. Because if requirements are not documented properly, you’ll likely end up delivering a solution that your customer doesn’t want or can’t fully utilize. Get it right the first time on requirements to avoid unnecessary rework.
Always communicate effectively. Always practice effective and efficient communication. And I don’t mean overcommunicate – that can cause it’s own problems. Your team will stop listening to what you say and stop reading what you send if you send too much useless information. And everyone will stop attending your meetings if they don’t convey meaningful information.
Use project management templates to create meaningful reports, notes, and schedules to distribute to your team and customer. Make sure your project status reports are informative and timely. Keep your project schedule revised and in everyone’s hands. Distribute status notes in a timely manner. All these things serve to better inform your team and your customer. And a well-informed team knows what they should be working on and they are usually working on the right tasks at the right time – greatly reducing the potential need for rework.
Monitor resource usage closely and forecast accurately. A revolving project team can often lead to rework as understanding of tasks gets confused and because different people do things differently. Bringing in a new tech lead mid-way through development can lead to inefficiencies in the development process which can often result in rework later on. Keep your resource forecast accurate and up to date so that you can keep them engaged on your project when you need them and so that you don’t lose them to other projects.
Have the customer plan and prepare for testing well in advance. Test cases and test scenarios need to be created and owned by the project customer. Have them prepare for testing in advance by taking ownership for these tasks. And have them start this process very early in the project. It will help the act of user acceptance testing go much more smoothly. Plus, if they know what they want to be testing for it will keep them from shooting from the hip during testing – a process that can often lead to misinterpreting results and causing unnecessary rework for your development team.
Summary
Rework happens. It happens on nearly every single project. That’s why it’s crazy to plan your project budget so close to the bone that there’s no room for any small amount of rework. But small rework issues should not bring down the project – and they just don’t. It’s the big rework issues that kill the budget, upset the customer, frustrate the team and upper management, and bring a project to a screeching halt. That’s what we’re trying to avoid like the plague…that’s what these processes should help to eliminate.
RSS Feed
