The above question was a topic of discussion in one of the forums on LinkedIn recently. "Sandbagging" refers to delaying (or timing) the reporting of certain project accomplishments ("good news") to maximize the (monetary) benefits and goodwill that may be accorded to the project manager and team.
Reporting the status of a project accurately and honestly is the right thing to do. But I find it troubling and disheartening that the above topic even warrants a discussion. It is an indication of a lack of trust between the business side and the project team.
Speaking from my area of expertise - IT/technology projects - the reasons for this mistrust are manifold.
The project manager is forced to commit to a plan with dates and deliverables even before the project starts. Much of the plan is speculative during the initial phases, which means that the PM is forced to pad the time and resource estimates because, as we know, once a plan is published it is cast in stone and expected to be signed in blood by the PM. (Come on guys...how many of you have faced this situation? The requirements are not clear. You are being forced to deliver a plan. You have no idea how long it will take? What do you do? You take a best guess and double it!! Sounds familiar?)
Well, the business side knows that the PM has padded the estimates. So they force arbitrary dates and deliverables on the PM. What happens next? The PM and team take short cuts and cobble together something in order to show progress to keep the business side happy and off their backs. This is a terrible waste of money, resources and time. Why do we do this? The team instead of building a strong foundation based on sound architectural decisions that can support the business requirements, find themselves spending much of their time building specifically for the "show and tell" sessions to keep the business side happy.
If the team, in the unlikely event find themselves ahead of the planned schedule, they are reluctant to divulge this information to the business side because the common reaction from business is to further squeeze the team on dates and deliverables.
It is about time that project teams are cross functional - business stake holders, users, programmers, analysts - must be part of the project team and fully committed. Remember the “Pig & Chicken” story.
A Pig and a Chicken are walking down the road. The Chicken says, "Hey Pig, I was thinking we should open a restaurant!" Pig replies, "what would we call it?" The Chicken responds, "How about 'ham-n-eggs'?".
The Pig thinks for a moment and says, "No thanks. I'd be committed, but you'd only be involved!”
We want pigs, not chickens.
The project execution timeframe is dependent on the entire team (not just programmers). As a team we need to understand that a project plan continually evolves. Good things happen because of the entire team. Ditto for delays and setbacks. We must celebrate successes and reflect on setbacks as a team. Project delays or cost overruns are not always because of the project manager and/or the team. Business stake holders are the culprits in many instances. They need to be more involved and take on more ownership of the project. The project manager can only be as effective as the support he/she gets from the business side.
Hopefully a cross-functional team working in a collegial environment – where everyone is fully committed - will obviate the need for "sandbagging".
Hey, a man can dream, can't he?