Have you ever, as a project manager, tried to slow your team down?
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
I'm just looking for personal experiences with this. It seems counter-intuitive for project managers, but I'd wager we have some real life examples from PMs on this forum. Maybe you needed to delay a deliverable for a customer, or perhaps you needed to coordinate work from different teams. Maybe you had an external dependency and you were at risk of getting ahead of it. Perhaps you were guarding your team from burnout. I'd like to know. Saving Changes...
In projects with lots of inter-dependencies between sub-teams, working too far ahead of other teams can result in a lot of rework and wasted effort.
I was working on a project where what is essentially the HVAC system was constantly undergoing design changes. My own team was responsible for the enclosures covering all their ducting, and was constantly having to redesign their enclosures every time the HVAC system changed. In order to quit wasting vast amounts of effort, I had to go into the change board, and request permission for my team to stop their work on the enclosure design, until the HVAC group "got all their ducts in a row".
They approved and we stopped work for several weeks until things had stabilized. Based on the facial expressions, I also got to see who actually read my charts. :-) Saving Changes...
John TiesoAuthor, Lecturer in Business Management| The Catholic University of America, Busch School of Business & EconomicsArlington, Va, United States
This can happen in a number of projects, and for differing reasons.
1- You have a relatively new, inexperienced team who thinks they know more than they do, and are anxious to proceed rapidly. The symptom for this is usually several minor, but perhaps conspicuous errors resulting in rework. get the team together, explain the need for more adherence to quality standards and review -- a bit slower but, over the course of the project it saves resources and time
2- As Keith mentioned above, your requirements and specs are in a state of flux. Better to slow or stop work--work on other, non-connected aspects of the project until you get something approved for development and production. if that isn't possible, you may have to shut down to avoid major rework or errors.
3-Changing scope, or scope creep initiated by the team and not the customer/client. teams eventually find 'better' ways to do things, and they expect the project leader will approve--so they go on and make changes to the production/development flow. If these have not bee cleared by the project leadership and possibly the customer, it may result in rework, and additional costs, not to mention a PR black eye for the team. Slow them down a bit and make sure the team members are adhering to accepted practice and procedures--agreed on in advance.
There are probably other reasons as well, but these are my most common experiences
Hope this helps Saving Changes...
I've run into this a few times, Wade, on technology projects - usually the counter-balancing constraint which I used to justify the decision was to avoid impacting quality. I'd also agree with Keith that if the work done by the team cannot be used by your project's customer in a reasonably short time frame, you run the risk of waste by building up excess "inventory".
Kiron Saving Changes...
Gordon AlexanderSenior Principal - Global Programme Director| IndepndentChelmsford, Essex, United Kingdom
Hi Wade, I agree with all of those so far, scope creep and resetting this, Changing specifications, aligning all projects timeframes when they get out of sync within a programme.
The other one I have come across a couple of times is changing strategy. When the organisation goes through a strategy change and want to minimise disruption they may stop a few projects and slow down others that may or may not make it into the "New" strategy. This saves the company time since stopping all projects for a few months can have a real impact even when this is agreed, i.e. when reconvened the original dates are still a soft target and everyone gets to work weekends "yehh", not. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Not necessarily slow down as an ongoing action (or decrease of), but of a take a pause, let's reevaluate where we are and where we are heading. Saving Changes...
I'm working in construction site which is involve a lot of different company. In this case, we regularly need to coordinated each differ companies to complete the work, also we had a standard priority schedule you have to follow it except you want to do a lot of rework. So, depends on those factors, sometimes you need to slow down your team because other people didn't finish their work. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Another reason for slowdown was to celebrate, take a time-out and appreciate the work done so far. Saving Changes...
Wade, it is my understanding that teams would have to be slowed down if the scope scales back, priorities change mid-way or requirements get re-purposed. In fact when you fall short of staff and need time to on board an extra pair of hands, you'd inevitably have to make the choice between work and skills usage. But the trade off would result in fewer goals being achieved. This is so that you're still leveraging all the capabilities without giving teams an unrealistic target to work with. Plus there's no law stated that whoever is slow is doing it wrong, or conversely whoever finishes first was right and a lot more industrious, it's a question of whether slowing things down gives teams a chance to fix things and recheck the work done so far. Saving Changes...
Yes, I had such an experience. As a PM you should be able to sync all teams and deliverables and it may require you to slow down your team(s). Saving Changes...
Sometimes when the team is eager to take quick solution decisions based on their previous experience and not eager to think about alternative options. Then I usually ask them to take a break, at first generate ideas alone, then brainstorm together, and review all the alternatives. In IT technicians got used to taking fast decisions but not always they are eager to listen to the rea client's needs and meet them. Better the take more time for decision taking rather provide to the client a solution which won't satisfy him and cover all his pains. Saving Changes...
