Project Management

Tell Me You're Going to Get This Done

From the Strategic Project Management Blog
by
As an "accidental" project manager, it's very satisfying to contribute to the project management community online with anectdotes and stories I've picked up from my own experience. I hope you enjoy our daily conversation.

About this Blog

RSS

Recent Posts

Tell Me You're Going to Get This Done

Quiting Isn't Easy if You Never Do It

Getting in the Way of Peak Performance

The Agony of Defeat?

Nobody Likes Being the Heavy



A friend of mine told me about a recent conversation he had with the boss. Due to circumstances beyond his control, the timetable for major a project originally slated to be completed by this time next year has been truncated to a due date some time in November. It seems someone on the executive team made a mistake and to rectify it, the project needs to be completed immediately.

Despite the fact that it will likely be impossible to accomplish in the new time box (I know, it's really hard to believe that anyone would rationally expect a 12-months long project could be completed in about 12 weeks), in a conversation he had with his boss a few days ago, the conversation went something like this:

"How are we doing on the new schedule?" said the boss.

"The team is doing the best they can, but I'm doubtful that we can get 12 months worth of work done in as many weeks," he said.

"You know if we don't get this project done, there will be lay-offs," said the boss in an accusatory tone.

"We'll do the best we can," said my friend.

"That's not the answer I want," said the boss. "Tell me you're going to get this project done."

In fairness, to help, the company has allocated additional resources and brought in new team members to achieve the objectives by the new deadline, but shaving nearly 11 months of a 12 month timeline just doesn't sound reasonable to me. Unfortunately, when my friend tries to explain the situation to his key stakeholder, it falls on deaf ears.

"If you don't get this done," he says, "there will be layoffs."

Meanwhile, the stress is starting to take its toll on the team.

Over the course of the last month, they made great progress. The extra team members working extra hours have accomplished more than would normally be expected, but it isn't enough. What's more, I can't imagine that management really believes this is even possible.

At some level, I admit that this is the life most project leaders live every day. "Tell me you're going to get this done," isn't that uncommon. What's more, often teams pull it all together and do amazing things. That's likely the case with my friend and his team. Nevertheless, doing more with less has really become doing more and more with less and less to the point that nobody has the ability to set realistic expectations anymore.

Is it possible that project teams are universally suffering from pulling a rabbit out of their hat too many times? Have we reached the point where we've exhausted our ability to reallistically look at the work that needs to be done and our capacity to do it and organizations just bite off more than they can chew as a matter of course.

I think we can all agree, at some point this reduces the teams ability to do good work and rather encourages teams to simply do whatever it takes to look like they're working.

What is your advice to my friend? How would you deal with an impossible to achieve expectation? Have you ever experienced something like this?

Posted on: September 17, 2012 05:50 PM | Permalink

Comments (20)

Please login or join to subscribe to this item
Hi Ty,
that''s an excellent subject. I have touched with my own hands this story many times. And it never worked out.

Usually, the duration of a project cannot be compressed by more than 10%-20%, unless there are few dependencies between the different work packages, few critical paths and it is easy to add new members (i.e. the learning curve on the project is very flat).

But in software that is usually not the case, at the point that one of the aphorisms in project management says that adding resources to a late project makes the project even later.


Just to add more fuel to the discussion:

It is well known that a goal challenging but achievable boosts motivation - but if the team feel the goal is clearly unachievable, the effect is just the opposite: the team know they are doomed to fail and motivation gets low, and so performance. The project becomes a "death march", nobody would want to join and existing project members would immediately try to escape and find a better one.

If I were the PM, I would just step back saying that I''m not intelligent enough to meet such a challenge. I would call my architect and my team leaders and ask, in front of the big boss, if they feel confident that the goal can be achieved.

You can't just say "yes" just because you have a gun pointed at your head, like that boss is doing. Better being fired but keeping a good reputation that being fired after the project has miserably failed, which would hit your reputation and self esteem.



Normally this might be a "fast, good or cheap - pick 2 of the three", and maybe you could go the agile route and ask what scope they want to drop to get it on time.

But actually is this one for the "one woman can produce a baby in 9 months, but nine woman can NOT produce a baby in one month" ?!

All good comments. The driver is all about saving face for an executive that made a mistake. In this case, the good, fast, cheap applies in spades - with good the one to suffer because no matter how much money you put at this, you aren't going to do a good job. (If its a software project, has COTS been considered - Commercial Off-The Shelf software?).
.
Expanding further on Cathy's comments, what can reasonably be delivered in 12 weeks that still saves face? 12 weeks is still roughly a quarter of the 12 months, so if you prioritized deliverables (aka agile) in terms of value provided, could you provide, say 50% of the value or functionality for 25% of the cost / time? Using the pregnancy analogy, perhaps that's not realistic given that some aspects may take a certain amount of time regardless of the resources applied, but still, can a major feature be delivered to keep the hounds at bay? Is it acceptable to deliver something as phase I, and the rest in subsequent phases?

These are all great comments. I've shared them with my friend. He particularly like Cathy's comment and said that it described the situation perfectly.

He's actually taking Massimo's approach. It feels like a no-win situation to me.

randa
I had a project like this a while back and survived. We delved deeper into why the timeline changed so radically (root cause analysis), and found that the executive's main requirement was for a pretty major organizational structure change, which we accomplished during the very short window timeline. We also identified impacts to IT systems and completed business requirements and business process redesign and documentation among all the functional groups involved. Systems work was then worked and completed within a more reasonable timeline.

I was thinking about this problem yesterday night before falling asleep. Randa's comment is very appropriate.

Very often we could step up a bit, become more business-aware and ask ourselves (and then the boss): why do we need to this? what is the business driver behind the request? Are there better, smarter and faster ways to achieve the same business result?

Very often alternatives are not properly explored. Spending a bit more time before committing to a project (or changes to a project) can address unstated requirements that even managers are not aware of.

That being said, if changes to the project are really necessary, I've never seen a project succeeding when compressing 1 year worth of work in few weeks unless the scope is significantly reduced.

I've reviewed a couple of these preposterous projects on my blog at Project Times. There's 3 options:
- quit
- try your darnedest and fail anyway
- get the bloody stakeholders (decision makers) into a room and cut, carve and shape until something reasonable and tangible emerges, or not.

It's not clear who the stakeholders are from the description of the problem, but as a PM, you want to spread some of the heat to the sponsor and the targets. Collectively they should be sharing the challenge with the PM.

I just read Daryl Conner's Change Thinking in the same issue as Ty's post. It's very relevant to this project. Check it out.

I believe Neal Partington and randa provided the best answers.


Determine what can be accomplished within 12 weeks and present that as the approach. Talk to the key stakeholders and find the key attributes that are needed. Involve the stakeholders as you cut scope to fit - they are probably already motivated to hit the deadline and likely be willing to give up personal priorities to make it.


Take the deadline seriously and scope the project to fit. If jobs are on the line, extensive overtime may be justified. Find out the key drivers and ensure that the project will deliver something in 12 weeks.

Very good article and I have been in this predicament before. I was working for a national telecommunications company where this happened. The director of the department kept changing and moving the milestones and brought them closer and closer to yesterday and there was noone to say that it couldn't be done, even his business operations manager said to bring in the reigns and do it even sooner. Bureaucracy is something I do not like now. The hierarchy simply does not get the point. So thanks for the article and the comments, I am glad I am not the only one in this predicament :)

I've been a PM since 1983 and seen most of the nonsense that happens when someone under estimates the scope of a project or flat out "over promises". I've also heard this layoff talk before, too. If it was that serious a situation, where's the COO or CEO or Chairman of the Board? Are they sitting in the project meetings now or letting some flunky middle manager "keep them informed." If a project's nondelivery is that serious, it will also make a serious impact on the corporate bottom line, so one or more of those people should be involved.

Enough ranting; now it's time for reality.

It's fairly obvious no one created a good bottom up estimate for the whole project, so as so many people have stated, figure out what the immediate "end state" needs to be, then time-box what it would take to deliver that capability. Ask the project's sponsor if he or she can provide sufficient resources to run two shifts on speed delivery of whatever is needed right now. (Yes, two shifts--day and evening--so you can double the project's daily accomplishment. After all, this is a very serious project that must be done to prevent layoffs, right?) If this project is that serious to the company or agency, then the two-shift approach may provide a way to deliver a minimal amount of project deliverables in a fairly swift manner.

I hope whomever is involved with this project will create a good project schedule (Gantt chart, if you will) in MS Project or something else and create a PERT estimate for each and every task that rolls up to a deliverable for this "immediate delivery". At least in this way, you can have an unemotional discussion with the project sponsor and anyone else. If you don't have that sort of validated estimate to show them, you're blowing smoke in their eyes. Yes, it will take time, but since no one had time to do things correctly before, now you have to make that time.

BTW--I had to help a company recover from a botched ERP implementation years ago that left management with no profit and loss reports like they had in the old (pre-ERP) systems. I had the CEO, CIO and CFO in my office, using my whiteboard and markers, showing the Chairman of the Board the minimal reporting they needed within several weeks to continue to bill Medicare for services. (Medicare billings were 97% of our $187M in revenue (1998)). The Chairman facilitated this working session while I wrote the notes and listed the data fields they were calling out to go into the reports. Yes, this was a "save the company project". If you do not have that type of high level involvement, something's wrong of the troubled project that has to be done "now" is not really that important to the firm's survival. (In our case, we delivered the functionality on time several weeks later.)




The situation really calls to bring in the agility ,considering the entire backlog and picking the most wanted and valuable deliverables to be worked on . In addition to that the system analyst / business analyst are to watch what parts of the required deliverables are commercially available and can be integrated maintaining a certain level of quality . The scenario above is so typical in software market but commitments if made with the consensus of project manager and team can make them negotiate the time lines to a certain extent where stakeholders on both sides have got to lose bare minimum .



I would not comment on the previous comments, I would prefer to comment on the initial topic 'Tell Me You're Going to Get This Done" .

I personally agree with the boss.

Often in my project delivery experiences, it is not workable to project team / project lead to finish a project without commitment at the very beginning that the schedule could be achieved on time.

In fact, it would have delay anyway but the delay is acceptable rather than not getting the commitment at the beginning of the work.



Regarding a line in your article "I think we can all agree, at some point this reduces the teams ability to do good work and rather encourages teams to simply do whatever it takes to look like they're working." t. I have dealt with these situations many times and will be dealing many times throughout my career.
In my opinion you are right. In addition to your point i would say innovation factor among the project team is hit hard by doing this.

An executive made a mistake! so pass on the monkey to the PM ! this calls for an immediate critical review of the project to realistically determine the duration if it can be completed! and if not completed as demanded by the executive peoples jobs are on the line! its blackmail ! seriously!... the only alternative is exactly what they did! to bring in extra help, more resources shelving other projects to ensure the business critical project is delivered! but at what price! probably another project to correct the short cuts and mistakes made! seen this approach during my career as a Project Manager! 'lets deliver and then lets go back and correct! ...........



Great discussion!

I learned much from this discussion. Thanks!

Dear Ty
Very interesting is your reflection on the theme "Tell Me You're Going to Get This Done"

Thanks for sharing

There are situations where a shortened timeframe can help the team work a little harder to achieve project goals and deliver while maintaining customer value.

In this situation we are talking about a reduction to 25% of the originally planned deadline

Either the project manager and the team misjudged the project (case for resignation) or, if you want a reduction in this timeframe, it is the case for the project manager to resign

Please Login/Register to leave a comment.

ADVERTISEMENTS

"When a stupid man is doing something he is ashamed of, he always declares that it is his duty."

- George Bernard Shaw

ADVERTISEMENT

Sponsors