When a project falls behind the schedule.....
-
Many years ago my manager gave me a book 'Code Complete (Microsoft Porgramming)' by Steve McConnell.
It said when a project falles behind the schedule, adding people is not the answer. It is because training the new people up to speed and learn a new system takes time. They are not going to be productive immediately.
Then what is the right way to do?
-
Depends how far behind schedule you are and what the causes are.
If the project manager under-estimated the timescales then there is not a lot you can do about it.
If you are going to deliver bad news then I would avoid a drip feed of bad news because management will get the idea that whenever you open your mouth they are going to hear something bad. Give them worst case scenario, stressing that it is worst case scenario and wait until they stop ranting and raving. you should then be able to have a rational (but not necessarily constructive) discussion.
The next thing to do is examine the critical path for the project. Are the dependencies for the project correct. Are there any tasks that can be brought forward?
Can you renegotiate when resources will become available? For example, if a DBA is an essential resource but is taken up on other projects until a set date can that DBA be released from the other projects or have their time leverages so x% of their time is spent on your project?
Most decent PMs will have built in contingency into their projects. I know a few who deliberately add non-essential tasks that can be taken out later if need be.
The best quote I heard went along the lines of "It doesn't matter how many men you put on the job, it still takes 9 months to make a baby"!
-
Have that book myself and it is really good. It depends on the project and the needs to be met. Sometime you have to readjust your schedules because you will never catch up. His point in the book is the general consensus is to throw more people in the project and that in itself creates a bigger issue with they must be trained to do the work. There can and will be exceptions to that, if you have 5 people on the sidelines who are waiting on a project and they are familiar with the current project then there is no learning curve and you can bring them in with a positive effect but if they are not familiar it can have a negative impact on the issue making it further difficult to catch up.
Point is review the problem, make sure it is a problem, if it is consider reviewing the current timeline to see if the issue was internal or external. If internal (maybe you mad some bad assumptions on productive time or you didn't figure in known constants like meetings) you may have to review and change your release timeline or break into smaller milestone releases. If external determine if they can be avoided (ex. support of existing system, find another person to do that support). But don't assume more people means less time ever, in fact as the book states the more pieces that have to fit together combined with more people on a project can actually have the opposite affect and take more time in unit testing, documentation and interteam discussion that a simple project of the same size (few interacting peices).
-
I always heard it was women you put on the job.
Also I think Steve's comment which I will try to check is that adding people is not always the answer.
Besides in light of the previous, if you have a single form which is under developement and you put 2 people on it then unless they work together on the same machine overall it will take longer for both to workout interactions han it might have taken for 1 to perform themselves.
-
I think Steve was paraphrasing Fred Brooks: Adding more people to a late project makes it later.
The reasons above are pretty accurate and the classic example is 9 woman cannot have a baby in one month. Use that when your boss gets angry.
The what to do part is interesting. The first thing you need to do is not bother the programmers working on the project. At least not immediately. Then you need a PM to decide if you need to triage things or take a longer term view.
If this is a short project, meaning due in the next 3-4 months and you realize it's late, then you have a few choices. You can remove any obstacles from the current staff and get them to be more efficient. If that means the CIO needs to make Starbucks runs, let the CIO know that. You're trying to get more productivity, but you don't want to create a death march for the programmers. For a month or so I think you can get some people to be productive at 80-100 hours a week. Most can't. Most don't want to if they have families, so you have to give them an incentive. And no, the fact you pay me isn't an incentive.
It's hard to bring people on board a project without disturbing those working on things, so that's where the delays get longer. If you've got 6 months or more to get to completion, then maybe you can spare a week or two to get someone up to speed, but that means training. It's not interviewing.
If you can bring in people to test, to QA, to write modules that someone doesn't have to train them on (as Antares mentioned), then you can do it, but there's probably a cost here somewhere for short term help.
The whole analysis, figure out what went wrong, etc. is something that I think is better left to a PM or manager without disturbing the programmers. If you need their input, then just wait until they're done. Figuring out how to do it better is for another day.
-
In the book Steve said when a project falls behind, the most logical thing is looking to see which scope can be delayed for next phase.
Actually the big projects I worked with (from six months to 2 years)
The most common reasons why it fell behind were
1. Project planning and scope was not clear, business users could not decide what they wanted.
2. Incapable project leader - happens all the time (actually it is happening at my current project)
3. Incapable developers - had the wrong persons doing the wrong jobs. SQL deveopers could not right SQL code. SQL DBA did not know what he was doing.
4. There should be a change control in place, at a certain point of time, the project leader had to evaluate the change control should be put in the project or delay for the next version. I remembered in my old company the users wanted changes at the end and the manager agreed to do it. The testing was not thoroughly because of constant changes and after it released into production, the system had so much problems even the CEO noticed and was so upset.
-
Those are definitely good ideas and that's a great book, but in a lot of cases I've worked on projects that couldn't be phased. Usually if that's the case, you need to plug along and try and get through it.
The key is the PM. They need to focus the developers as well as remove distractions. Hard to find a good PM to do that.
-
I agreed Project manager was important and in all my career and did tons of projects, I probably met only two that were good.
But another important pieces are the developers. In my previous company, it decided to implement a new ERP system written in VB6 and Oracle and ran under UNIX. All the programmers were main frame programmers. There were no training provided to any of them. They hired tons of contractors, some were good, some were not. It ended up they did not allow anyone taking vacation, work 6 days a week even holidays. I was one of the contractors and I worked 60 hours a week.
Sometimes companies just did not think about training and thought their employees could pick up anything. The VP of IT said SQL was so easy even the cave man could do it! Unfortunately none of his employees were cave man !!!!!!
-
I think every serious delay I have ever seen in all the projects I have been involved in has been due to scope creep, which I guess comes right back at poor project management (and poor setting of expectations from the start).
Which is why I prefer to stay a lowly DBA instead of being a PM...
-
Scope creep is a big one. This is one area where as a PM you've got to take as much a stand as you're capable of making when it starts to happen. I know you've got to pick your battles, but 2-3 "little" additions may cause more trouble than 1 big one.
There is a saying in PM circles, "Pad is bad." This is the idea of building in extra time to ensure you have enough time to meet deadlines. Pad IS bad. If you're just adding time to be adding time, that's not good. You're going to get scrutinized when you come in WAY under estimate or someone notices no one working because the deadline is too far in the future and the work is about done. But it's not unrealistic as a PM to consider the politics, the likelihood someone is going to get pulled off a project, the fact that people are going to take sick days during the wintry months, etc., and adjust times based on that. Sure the developer told you 20 hours, but if said developer is production support, perhaps 24-30 hours is what you give the task because you KNOW said developer is going to get pulled off and he or she is going to lose time trying to switch off to work on production and then switch back on to work on the project then switch off and then back on, etc.
As to the original question, as a PM I sit down with my key people (tech leads, critical stake holders) and I take a look at why we're behind. A lot of people say come up with a plan and here's what I tend to do. We discuss what the main causes were and if they could have been avoided (because managment is always going to ask). We discuss which of these causes could repeat themselves (if John is always calling in sick when a new XBox game releases, don't expect that to change without intervention). We discuss what the critical path items are, what we can do to get them back on-track, what work we can postpone, what work we can cut unless we find time later in the project, where we might gain time back later in the project, etc. You get the idea. For features that aren't critical path, we look at the estimates for them. We rack and stack them. Management may decide that cutting some features that aren't crucial is the best way to save time and money. Give 'em the knowledge to make that decision. And above all, keep a level head. If you're screaming the sky is falling as a PM, everyone else, including management, is going to start getting worried, too. And that always slows things down, making timelines worse.
K. Brian Kelley
@kbriankelley -
Project Life Cycle
1. Set delivery date.
2. Code until the day before the delivery date.
3. Do some half-assed testing.
4. If test results are good then go live else go live.
5. Declare success and celebrate.
6. Define requirements.
7. Repeat from step 1.
-
Excellent! Define requirements might be step 5, but more likely step 6.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply