Ask HN: As a team lead how to handle project going off the rails?

[le-mark]

This is kind of a banal story. I'm the lead developer on a "modernization" project that's taking a lot longer than anticipated (you see where this is going). The team is great, it's just that the work is way outside their comfort zone. The business has been selling the new version pretty hard and we're not going to make the release (about 3 months to go).

Question is; as a lead how would you handle this? I think my direct manager has a healthy dose of skepticism about the timeline, but the product owner doesn't. At what point should I start sounding the alarm? I'd like to give it a couple of weeks and see if the team picks up pace but I'm not confident.

[ljw1001]

This is not going to be like the other advice you get, but I've managed many projects in different organizations and I think it is sound. First and foremost, don't sound any alarms.

Many organizations have common characteristics in this regard. First, they don't expect you to be on time. Sales may think you're going to launch on time, but it's in their financial interest to think so. The rest of the org probably made a schedule they know you can't meet because they think it motivates you to work harder.

Second, unless you're in a startup where everyone's inexperienced, most people probably already know you'll be late, but aren't saying it out loud. They likely have discussed it (up the chain) in meetings you're not in.

Third, people do shoot the bearer of bad news. You can earn a rep as a negative person if you make _true_ predictions out-loud that don't fit the common desire. This is especially true if some of the senior people who know (like your boss) haven't been forthcoming with their bosses.

Have a quiet conversation with your boss over lunch or beers - not a meeting - and tell him/her what you think. Be prepared with details, but if he/she doesn't ask for them, don't provide any. There's a good chance he/she already knows as you suspect.

Even more casually (lunch/beers), express your concerns to the project owner. It's probably not new news to him/her either. Being "positive" is a huge part of the corporate game.: Again, if no details are asked for, don't provide any. Shift the conversation to the weather or the world cup.

You're now down. Go back to work.

[tootie]

Disagree. Just be real. When I joined my current company, they had a project kicking off with a ridiculously short timeline. I asked the product manager to think about how many stories were in the backlog, how many might be added as we went, how many stories they could get through per sprint given the team capacity and then you can put a rough date on it and continue adjusting every sprint as the backlog shrinks and you get a clear picture of velocity. Our first pass put us about 400% over the allotted time (an estimate that has held up pretty well since then).

Next step, is to spell this out to your project team leadership completely unvarnished. Tell them your conclusion and how you got there. Don't let them bargain over your reasoning unless they actually have better evidence. The key is to never say "this is too hard" or "we don't have enough people" or make any other excuses. Not should you be overly emotional. Just give the facts. It's a fait accompli.

Then just ask how they want to deal with it. There is absolutely nothing to be gained from beating around the bush. I've done this more than once and was always taken seriously. One time we had even already signed a fixed-bid contract before I was able to give them an estimate. What you've committed too doesn't change the course of what's actually going to happen.

[lostcolony]

So much this it's painful.

You will never be thanked for telling them uncomfortable truths, even if they -don't- know. Even the private conversation is dangerous; as you say, keep it as low key and minimal as possible ("i have some concerns about the timeline" is literally all you should say unless they ask, and your answers to any followup question should be equally circumspect).

Instead, as others have mentioned, just make sure you document what does get done. Ideally have a decent backlog of things that need to get done, but that presumes a PO who does their job (and it sounds like he/she probably isn't). That's your CYA, and your innocent response if they ask why you didn't raise the alarm.

[crispyambulance]

Well put.

Deadlines often slip. It happens ALL THE TIME, regardless of elaborate and sophisticated project management techniques and skilled contributors. Deadline slippage is also RARELY FATAL, but yeah, leads/PM's can absolutely get themselves metaphorically shot by bearing bad news to the wrong people at the wrong time.

Some orgs hire a ridiculous number of PMP's who pretend like they're making a difference but are really just practicing an elaborate dance of goal-post-moving to appease the deadline-gods. People in such orgs often bullshit about a "track record" of being "always on time and under budget".

Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.

[sailfast]

This advice is a good first read on the political elements before you make a real move, but it’s not a plan, and it sounds like a recipe for mediocrity. (Not that there is anything wrong with that)

If you actually want to have some integrity when you talk about deadlines before it eats up your insides and you lose sleep you will need to have these beer / lunch conversations to gauge the level of appetite for change and then start talking about how to get something shipped on time as well as the consequences for not shipping on time.

Sounds like you already have this dialog with your manager. Keep talking about how best to manage expectations up the chain.

You’ll want to get buy-in to reduce scope or make whatever other changes you need, otherwise you’ll have to lie to keep up the facade that things will ship on time. It will burn you out.

If the read in the parent comment is bad for your org and it’s NOT normal to BS deadlines and ship late then no paper trail or written warnings, risks, and issues brings with it some badness as well - judge for your organization. I’m guessing you may already know the answer.

This is probably not the best career ladder advice at some firms, but at all costs make sure you never lie for anybody. Keep your integrity. Be honest. Sleep at night.

Of course sometimes “honest” is an excuse to be pessimistic. Look hard to make sure your dire warnings are not “chicken little” pessimism, then talk it out with your management, but don’t lie for them and be honest about your engineering and your team.

[blablabla123]

> Third, people do shoot the bearer of bad news. You can earn

> a rep as a negative person if you make _true_ predictions

> out-loud that don't fit the common desire.

I've heard this very often, both as advise, complaint and even in an intimidating manner. And yes, I've seen this, people who stay kind of positive stay in their position even if they screw up a project completely so it has to be "rebooted". In fact I've also observed a super negative person, being a colleague of mine for 2.5 years and staying good with everybody despite one screwed up project.

On the other hand people have put me in various settings under high pressure to keep my mouth shut both internally and externally. (That was only in the startup/co-founding setting though.)

My conclusion: I'd take this advice with a biiiiiiig grain of salt. In my experience people get away with everything as long as they stay confident and keep their shit together.

Disclaimer: I'm not a team lead

[ptero]

This is a good advice and all three points are spot on (on time deliveries are unusual; management likely knows you are late; messengers often get shot).

You do need to figure out for yourself a realistic, pretty safe time when you will be ready: an extra month? three months? never? You say the work is outside your team's comfort zone. This is potentially a much bigger red flag than being late. Will the team learn and deliver, or it just cannot execute at the speed requirements are changing or will soon be? Be brutally honest with yourself.

If you think you can safely deliver the product in, say, three extra months, then keep working but be ready with good estimates when the time comes to redo the schedule. When that discussion comes (usually suddenly), having a clear plan and realistic estimates that you can confidently present will likely give you (most of) what you ask for. IME really bad options are either agreeing to fix everything in a week (if you know it will take three months) or not having an estimate at all "we are burning midnight oil and I cannot tell you when we will be done". Either could lead to quick problems.

IME when "what do we do with this crap" time comes, senior management does not care why you are late (everyone is at least some of the time). They want to know if you have a plan and look ready to execute it. Just my 2c. Good luck!

[cmicali]

Strongly disagree. I think this is the cynical view, and I'm sure is valid in many companies, but raising potential issues early is really important - other people can't fix problems if they don't know about them. It sounds like you have visibility into a problem that others may not, tell them! Don't assume people already know.

Like some of the other posts said - be real. If people don't respond well to this then the company has a bigger problem than a slipped schedule.

[Talyen42]

This is the only really true, non-theoretical advice in the thread.

OP's description is generally how every project at every company has ever worked, forever.

[chiefalchemist]

> "Third, people do shoot the bearer of bad news."

True. But under such circumstances chances are pretty good someone(s) is going to be shot anyway.

I think the answer is solid. But if going this route I would update my resume and reach out to my network.

If this ends badly you want to be prepared.

[thisisit]

> Third, people do shoot the bearer of bad news.

As someone who has been a bearer of bad news, this is a sound advice. Most of the time you are told - "At least give it a try". And even if you tell them - "I did try but still likely we will miss the deadline". They will ask you to check again.

It is mind-numbing when it happens the first time. And most of the time you get disillusioned and think - "I need to look for another job". Guess what? Every corporate works like this. All about positivity and "You can do this" messages. And most importantly people setting up super-aggressive timelines knowing well that you are going to fail.

> Second, unless you're in a startup where everyone's inexperienced,

Curious about this though. So, as per you startups are run by people who don't know how to run projects?

[gascan]

Caveat, this seems to play out fine if the project slips 10-20%, which is sort of within expectation, and your competitors may be slipping the same amount as we speak.

If however the project is due to slip 200%, or 400%- I guess I don't have specific advice, but that kind of project is the sort of project that can sink a company. Of course, you only really get to that point if vice-bigwigs are lying severely to the bigwigs, in which case there may be nothing a team lead can do about it.

[jobu]

> Be prepared with details, but if he/she doesn't ask for them, don't provide any.

Also be prepared with solutions. Any decent manager or product owner is going to ask things like: "What's a realistic timeline?" or "What could be cut to get closer to the timeline?"

It would worry me more if they didn't ask details. In my experience that means they sent you on a fools errand expecting you to fail and take the heat for it.

[forapurpose]

I agree with much of your premise but one problem I run into: If you have these off-the-record meetings, where is your documentation if they say, 'I didn't know it would be late'? In my experience, people not only dislike bad news, they ignore it:

First they hear what they want to hear, i.e., what is not threatening to them. 'Project delivery will certainly be late' is heard as 'the next milestone will be late' or 'we're a little behind schedule and will catch up' or 'it's making another project late', etc. It's truly incredible what people will construct in their minds. What's the saying? 'Don't expect people to understand what their salary depends on them not understanding'?

Second, like everyone, they ignore or put off dealing with bad news. (Probably, that's a temptation of the OP.) Then they say, 'I didn't know.'

It depends on the people and the organization, of course, but you do you protect yourself from being thrown under the bus?

[OliverJones]

This advice is spot on. I would add one thing: make sure you don't surprise your manager. Talk to her. You and she should be on the same page about your project's progress.

It's her responsibility to help the rest of your business do the best they can with reality. If sales of your existing product have dried up because prospects are waiting for the modernized one, that's a big problem (been there). But it's a problem belonging to product and sales management, not you. Unless you are a founder.

Renovating software is hard, much harder than greenfield software. All the best to you.

[barrkel]

This is the right path if you're a lead on one team of many in a larger org, you don't want to risk needing to find another job, and you don't have a burning desire to make a difference and build a track record of change.

If you're in a smaller company, and you have clout due to being closer to the top of the food chain, and you have a vested interest in the success of the operation, to the point that it's worthwhile cutting your losses and moving elsewhere if the outcome isn't positive, then the higher risk strategy of pushing for change makes more sense.

[jf-]

OP needs to be concerned about the blame game if the project is a big deal. The manager won’t want to take blame, same for everyone else in the chain. The best thing OP can do is raise it quietly with the manager, and not terribly forcefully, note that this was raised. I also think going to anyone other than the direct manager is a bad idea. Then take some actions that can be used in retrospect as evidence that OP was trying to ameliorate the situation. Fundamentally this is a management issue, don’t let it become a game of blaming engineering for management’s flaws.

[Zeebrommer]

I hate to agree with you. This honesty/positivity dilemma is something I'm struggling with.

[notyourwork]

My old boss had a phrase, "bad news doesn't age well". I have followed this throughout my career and it's served me well. I have not found it to be bad to be the bearer of bad news. I have found that it makes me perceived as transparent and honest about expectations.

Bearers of bad news are frowned upon when the bad news is their fault and not presented when its determined to exist. I think this is a distinction that should be made with your phrase.

[Chyzwar]

I suspect that you did not managed expectations. PO was not really working as the proper owner and have no clue about progress and effort being put. Your direct manager does not care as it can always blame everything on you. And the team is not so great if they have problems with "comfort zone".

First get PO on board. Choose the process that will push PO into the central role: Kanban, Scrum, XP(anything really). Work with the PO to create user stories, estimate and calibrate. PO should work with stakeholders to ensure that the timeline is realistic.

Get your team a proper training. Hire someone to do training on the tech you use. Get some courses from Pluralsight/Udemy that will be mandatory for everyone on the team. Extra day in month spend on training is not much but it will up-skill people quickly.

Drag in your manager. Get him into a meeting and ask for a guidance of the senior manager. Make him co-responsible, he might help with funding on the project. Cut features to absolute MVP. If nothing works, escape sinking ship.

[adrianhel]

And if it's an online solution, propose to roll out some features gradually.

But yeah: 1. Be honest with everyone 2. Invest in online courses for everyone 3. Lay out a simple roadmap for the minimum MVP 4. Hustle

And next time use my recipe for estimating. Spend ~ a day on this.

1. Split up everything into the smallest subtasks 2. Estimate the time all subtasks take. Uncertain? Write down a low and a high. Still uncertain? Split the task into subtasks or confer with someone. 3. Add the times together and multiply by pi. If applicable, do it once for the high and once for the low. 4. Present the high estimate. It is probably closer to the truth. Estimating the low as well is more of a psychological trick.

Don't use the subtasks for the development though. They will be too fine grained.

[kimdotcom]

This is the best advice here.

I would work for you.

[jasonm23]

Assess the product delivery in terms of risks. Look at what's on the roadmap and build a 2x2 matrix of the intended features.

Get some post-its and write down each feature. Organized on the 2x2 with these axes X: "risk/complexity" Y:"desirability" (that's business & customer desirability.)

Setup a meeting with your products owner and others to try and get a good deal of feedback and communication, reorganize the 2x2 matrix during the meeting to build understanding of risks and priorities.

With everything on the table the big risks should be clear and addressable. The product owner will be able to make some changes to the product plan.

Visibility and transparency is key, don't do an ass covering exercise, and act sooner.

Make sure you understand what has been difficult and outside the teams comfort zone, where improvement could be made etc.

Also be aware of the motivations for the product owner and empathize. Build & strengthen that relationship.

Better feedback loops, better clearer/slicing of feature requirements... I could only generalize, but aim to improve communication and even if all goals aren't met it will be a healthier place and contingency will be easier to work on.

[blahblahblogger]

> Organized on the 2x2 with these axes X: "risk/complexity" Y:"desirability" (that's business & customer desirability.)

Not to sound like an idiot here or anything, but does that mean something like this: Risk | Complexity ---------------------------------- BiZ desirability | | ---------------------------------- Cus desirability | |

Can't an item be in many of these squares?

[bbrunner]

Tell the product owner what the situation is and collaboratively come up with either:

a) a new timeline that you believe you can meet or b) a list of tradeoffs that can be made to get the project out the door in time

I have been an engineering lead and a product manager and it is much better for everyone to just be upfront about all of this.

You know what your team can produce and (roughly) how fast they can produce within an order of magnitude time-wise. The product owner should know what stakeholders actually want product-wise and what an acceptable timeline looks like. You should be able to work together to narrow the scope of what is being worked on to a point where your team can accomplish it within the timeframe.

Communication and setting expectations are key. This needs to be done both up front and on an on-going basis. As an engineering manager, you should be able to evaluate, week-to-week, where things stand and which tasks may need to be cut to make a deadline or how far a deadline should be pushed back if things can't be cut. Your product owner should be able to weigh in on this and should already be prepared to pare down requirements if necessary.

It may be painful and embarrassing to start having these conversations now, but it is significantly less painful and embarrassing than having these conversations in 3 months when the product is expected to be delivered.

[jacquesm]

It sounds to me as if you're doing a 'big bang' when you should be doing something incremental instead.

Great way to lose your people because at some point the only way to make the artificial deadline is to increase the pressure on the team building it to satisfy the manager. Those that can move out will do so, you will be left with the people that do not have much in terms of options to finish the job.

This movie has played 1000's of times in badly managed tech companies.

[mathattack]

If you bury it as others suggest, you will lose credibility as a leader even if you have covered yourself. There is no good answer to “Why are we finding out about a 3 month slip the Friday before deployment? If we are 3 months behind shouldn’t we have more than a day of notice?” Execs hate surprises and engineers hate bosses who don’t tell the truth.

The key to surviving this is:

1) Informally let everyone who may look bad know the truth.

2) Gather data. (No metric is perfect but this takes it away from being about people)

3) When it comes time to present formally, list what you are doing about it and what everyone else needs to do. It should be worded as, “To hit this date, we need Jane QA to do X, Joe PM to pick the two most important features, bla bla...”

4) Document #3 in a plain-English follow-up email. List names not orgs.

5) Send weekly updates to number 4 in writing.

If people don’t give you the help you need, you’ve done your part. They also won’t be surprised.

In all of this, be specific, factual and unemotional.

[LoSboccacc]

Never let time pass. Project timeline slips one day at a time. As a lead your role is not to control scope, but if you feel your team will not be able to deliver by deadlines you have to make a case for it and you’ll need:

- A simple summary: we need to deliver by x but current estimate point at y being the delivery date.

- An estimate of delivery for each features you have visibility and their dependencies (not task, features. This email will escalate at some point and you need it be management friendly)

- A backing analysis to defend your task time estimate. Maybe as an external link or attachment.

- A suggestion on a set of feature you feel could be cut or postponed after release to keep the project within deadline.

The fire alarm need to be sounded immediately as you see smoke. Start with your direct manager, but first build consensus between the team: you’ll be squeezing the manager toward the owner, and for him tje path of least resistance will be to put pressure on you and the team.

[patan2]

Whatever you do, DO NOT ADD new team members to an already delayed project. It will delay it further. Break down the project into simpler tasks that can be assigned to a team member and be tracked. Attach strict responsibility of task to team member. And last and most important, talk to your Management about timelines. Make it very upfront that it will take X number of days and no lesser.

[mikekchar]

Words I've used with success before: "I've got some bad news. I've been running the numbers and based on our current progress, it doesn't look like we're going to hit our release schedule. Now, it's possible that we've just hit a slow patch and we will pick up steam later on, but my experience has been that this rarely happens. Everybody on the team is still really optimistic and we're working very hard to hit the release, but I wonder if we should start to make a contingency plan. For example, if we take this part out and plan it for after the release, I think it will help. If we pick up speed again, we can just roll it back into the process. I really don't want to add any more people on the team right now, because we have a really good chemistry at the moment. I don't want to risk losing time by trying to integrate someone new. What do you think?"

If the response is, "You'd better hit the dates or heads will roll", then respond with, "Of course we'll do our absolute best!" and start looking for a new job.

If the response is, "That's disappointing, but we can't change anything because all of our marketing/whatever is dependent on you finishing everything on that date." Respond with "Of course we'll do our absolute best! Let's see how it goes for the next 2 weeks and hopefully it will get better". Start poking around under the hood to see if there is any wiggle room for pushing things out (i.e. are you being fed BS, or is it really the case that the company is doomed if you don't deliver). 2 weeks later have the appropriate conversation. One time I had to say, "I completely understand the position we're in, but I'm sorry to tell you that the odds of us completing our part of the work on time is extremely low and I can't think of a way to fix the problem. I think we're going to need to work on a new business plan." Basically its realistically discussing the "we're totally screwed" reality. Try to find the best compromise that you can, while looking for a new job in the background :-)

Otherwise just play it by ear. Unreasonable product owners will be unreasonable no matter what you tell them. You might as well tell them the truth. If they are going to flip out, then let them. If your product owners flipping out bothers you a lot (it bothers me a lot ;-) ), then look for a new job.

However, my experience is that when you are not flipping out yourself and are open to listening to the other person's problems, usually good things happen. I don't often look for new jobs when my projects aren't working out as hoped.

[adrianhel]

If you get the marketing team response, determine what has actually been marketed. You can probably remove some things with noone being the wiser. Create a prioritised backlog. You'll be the only one knowing that feature X probably won't reach the release, but noone will care. I did this recently and everyone were excited about the release, despite pushing for some features that were labeled low pri.

[tobyhinloopen]

  > If the response is, "You'd better hit the dates or heads will roll", then respond with, "Of course we'll do our absolute best!" and start looking for a new job.

Hah

[sudofail]

This is really fantastic advice, and well said

[d--b]

A company is a company, your manager is in your team, the product owner is in your team, the salesman is in your team, the CEO is in your team. Talk to your manager, and your manager will talk to the stake holders to see what to do about it. Delays happen all the time. No biggie. Just try and understand what went wrong (to make sure the next one doesn't suffer the same) and how much time it will be costing. They'll be asking you anyways...

If you're in one of these companies where people are not allowed to screw up, then I would recommend you start looking for a healthier work place.

Good luck

[jezclaremurugan]

This contradicts the advice others are giving but in my experience here's what has worked for me. * Communicate early * Document the warning signals - have an email thread - this is critical in saving you later * You will be asked to hustle, have explanations for why hustling won't help reach the deadline * Have clear reasons why the delay is caused - why wasn't the skill gap known earlier?

Be ready to lose some weekends and burn additional hours - but people will appreciate your being on top of things.

People shoot the messenger - when the messenger is too late in delivering the warning when the rest of the business can't do anything to fix it. Even if management is anticipating delays - it will still look good on you that you are able to foresee problems, and your foresight will be rewarded later on.

People don't like hearing bad news - but if the bad news is delivered early and documented in such a way that it makes them responsible for not acting on warnings, they tend to work on it positively.

If you do the above and still get shot as the carrier of bad news - the work culture is toxic you are better off working elsewhere.

[ChuckMcM]

This is such a hard question because it is intimately intertwined with the culture of the organization in which the activity is occurring.

Bottom line, stay true to your own sense of integrity and be honest with whomever asks for your assessment of the situation.

I agree with the other comments that suggest you have conversations about your management and that you journal your progress and concerns.

The cultural question is around what happens when it is obvious the schedule is going to slip. In some organizations the group looks for someone take the heat and they heap a world of pain on that person. Generally that is the person who doesn't have any record to back up their assertion that they told everyone else it was not going to work. In other groups there will be a great ceremony of replanning and another unrealistic deadline will be pronounced and the cycle will simply repeat. Sometimes organizations will want to figure out how they got the schedule wrong and apply fixes (your journal will be invaluable there).

[larrywright]

The most important thing is to show progress. Agile/Scrum/XP are much-maligned these days, and with some good reason, but the one thing they do very well is to get you on a cadence of delivering working, demo-able code on a regular interval. Every situation is different, but in my experience being able to sit in front of stakeholders every couple of weeks and show them what you've just built, talk about what you're building next, and explaining anything that might impact that, gives people a lot more confidence in a team. In my experience, what scares stakeholders is when the nerds disappear for months at a time with only hand-wavey status reports to show how they're doing. Get them in a room on a regular basis, and demo what you've built. If you can't get them all in a room, record screencasts and share them, or demo over Skype/Hangouts/etc.

[boffinism]

> we're not going to make the release

> At what point should I start sounding the alarm?

Immediately.

IMMEDIATELY

[arendtio]

Well, ring the bell NOW so you still have time to act. Make sure you bring all the facts you have that make you think that you will miss the release. Ask your team what they think how much time it will take them, given that new evidence.

Then get everybody onboard (your direct manager first). Talk about the problems you have and how you can solve them. Make a plan that everybody believes in and set a new release date together.

In general, modernization projects are not about timing, but about high quality. So cost are the only variable here, making it important to know how much that project is worth for your organization. Is it just nice to have or critical for the development of the next years as it cleans up a lot of technical debt? Keep that in mind as the consideration of stopping a project is always on the table when it leaves its frame.

[muzani]

Yes, ring it loud. If you think there might not be enough time, there's almost certainly not enough time.

Start setting up meetings with the project owner ASAP. People are usually more angry if not informed. If they've been informed in advance, there are a lot of options that can be taken, and it lifts a little blame off the dev team.

[tobyhinloopen]

This was also my thought, hah :)

[aytekin]

You will not be able to release “everything” in 3 months, but what if you picked the most important parts and focused on getting those out?

[hallihax]

I think ljw100's advice is pretty spot on.

It's very tempting to think that on a practical level, people 'need to know' what's going wrong. Unfortunately it is often very difficult to accurately or objectively assess what the underlying problems are and in many cases, what you perceive as a problem can actually turn out to be a symptom of some other issue.

Project slippage happens all the time - and in and of itself it may not indicate any serious issues. It could just be a case of poor estimation, or scope creep, or some other 'process' related issue which is unlikely to be something any single individual can do anything about.

In my experience, the best way to deal with these kinds of situations is to make sure you're keeping your relevant colleagues up to date. If you feel like some deadline isn't going to be hit - it's probably best to voice your concern about that risk (and only that risk) to your immediate superior. In many cases it's likely that people are well aware of how behind things are - but everyone has a different assessment as to why.

In such situations it's often the case that the most you can do is to tend your own garden. It's important to keep the chain of command - even in small organisations (and especially when dealing with multiple teams / stakeholders), and avoid trying to assign blame (or even identify 'the cause') unless specifically tasked with figuring it out.

Basically: if it's not your job to raise hell about things, then don't. Keep your superiors up to date with progress and let them figure out the implications.

Although it can be intensely boring, project management tools can help to de-politicise these kinds of situations: graphs aren't personal, and the more regularly the relevant people can get a snapshot of progress, the less likely it is that it'll fall to you to point out when things aren't going as expected.

[convolvatron]

if you're doing it right, its not boring at all. its only boring if the work and the people are meaningless abstractions, which makes moving them around on the board pretty pointless.

if they are your people then there are all sorts of opportunities to reorganize what gets done first, and who is working on what, and how it all fits together.

you can take a unfocussed seemingly infinite amount of work and turn it into 'if we can just get this seed part done, then the rest can hang off that. jane and timmy, since you are both working adjacent to that piece, and I trust you both to sit down and make it happen - please do that'

thats the best part of the job

[rinka_singh]

* Put a risk database in place - what are the project risks, mitigation strategies, probability the risk will happen and the impact on the project.

  Start tracking this risks DB on a weekly basis
  Involve your Manager and the product owner in the risk analysis and mitigation task.
  It is shared responsibility of management.

* Use this to forecast the Estimated time to completion (ETC) - STARTING NOW,

  Each week update the ETC and show how it has changed as a result of the risk mitigation.
  Sit down with the product owner and juggle the features to get to an optimum mix of ETC, features and risk.
  He/She has to take responsibility along with you.

* Communicate, communicate, communicate.

  Up and Down and sideways...

Best..

[ochrist]

First: It's difficult to advice on these matters in cyberspace. But as I have been in similar situations, I can give you some general advice: First, break things up in smaller phases or sprints, setting some milestones based on sensible estimates. Get the team to commit to these estimates and the timeline. Second, ask the customer/PO to prioritize features (as others have pointed out) in Need to have, nice to have etc. Third, make the customer/PO prioritze what is most important in the project triangle: Time, scope, quality or price. If you make a simple plan (eg. a burn down graph), you can follow the progress and adjust the plan if necessary. You might consider doing a simple risk analysis as well. Good luck.

[wolco]

The best advice in the comments. You breakup the project into sprints and let the product owner choose priority.

[_dan]

Tell everyone there's a problem. Immediately. Make sure they understand that "working harder" isn't going to fix it.

Reset everything. Massively reduce the scope of the project and make sure everyone knows that's what you're doing and to expect to see something being delivered soon, but that it will be a small and simple component intended to get something out there.

Deliver the smallest useful thing you possibly can as quickly as you can, and show everyone,

Once you've delivered a few parts get a bit of momentum, get everyone together and hash out a slightly bigger next step.

[ransom1538]

For next week, get a list of things you can work on. Spend 30 minutes with the team monday morning deciding what is the most important to work on. Agree with the team these items will be done by Monday (if something can’t be done in a week break it down.) Execute.

Things cannot be* late. You are only on a week timeline. There is no other timeline. Forecasts outside the week are unpredictable and should be ignored.

This will give you a velocity (items done per week) and start quickly building team confidence. Things get done.

Don’t let anyone change or modify the week goals. If some one wants something they pitch for it Monday.