29 ms·

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

• PaulHoule 8y ago
  get some quantitative measure of progress (eg. make some kind of simple burndown chart)
• everdev 8y ago
  Set some interim goals, estimate them and measure progress. Take that progress and estimate the remaining work. There's no accounting for the unknown, but IMO it's best to raise the alarm as soon as possible. Just make sure you and the team have the ability to deliver the project, otherwise it's time for a different conversation where you look for outside help. As much as everyone hates deadlines they are important and try your best to meet them if they're realistic.
• deleted 8y ago
  [deleted]
• User23 8y ago
  Please forgive my generalizing, but there aren't a lot of specifics to work with. Scope creep is often a major factor in situations like this. In my experience product people usually believe that relatively small feature changes imply relatively small engineering effort, and of course that doesn't hold generally. Sometimes product people will try to sneak scope creep by as a "clarification" of requirements, which almost always leads to the situation you're in. So, depending on your environment, it may be constructive to draw attention to this, if it's applicable.
• q-base 8y ago
  If you are lead, then you should lead. If you lose faith, they lose faith. That being said, faith won't magically fix everything. If you are unable to make it, then figure out what you can deliver and then tell your manager/product owner. Deliver the "bad news" with a constructive alternative. Cut away some features and then going forward be ruthless about scope creep. Urgent thing CAN come, but then others needs to be removed.
• aytekin 8y ago
  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?
• quintes 8y ago
  Note the risks ( non delivery ), inform stakeholders, and plan a roadmap of deliverables.
• bbrunner 8y ago
  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.
  • deleted 8y ago
    [deleted]
• wiz21c 8y ago
  Question : why does it take longer ? Team ? Development process ? Strategy (by modernization, I think "rewrite", which is always hard) ? Question : how will suffer if you're late ? (no, it's not the end users, it's someone, somwhere who said it was possible, whose career path is tied to the project, etc). Make sure he won't suffer too much, that may give some room on the planning.
• Cieplak 8y ago
  Not sure if there’s a silver bullet, but there are certainly lead bullets. I found this really helpful: https://hbr.org/2015/01/what-everyone-should-know-about-managing-up https://hbr.org/2015/01/what-everyone-should-know-about-mana...
• Chyzwar 8y ago
  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.
  • kimdotcom 8y ago
    This is the best advice here. I would work for you.
  • adrianhel 8y ago
    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.
    • kefabean 8y ago
      The multiply by three approach has also worked for me in the past. People often estimate the time taken to do the task, typically not taking in to consideration the other aspects of their job (eg comms/planning/rework/productionisation/etc) needed to get said task done. I do like the use of pi though, I’ll be adopting this going forwards!
• rinka_singh 8y ago
  * 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..
• jacquesm 8y ago
  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.
  • rejschaap 8y ago
    Incremental is key here, 'modernization' sounds like a large and blurry goal. You need to get this under control as soon as possible, definitely don't "give it a couple of weeks and see if the team picks up pace". Start making lists, what has been done, what needs to be done, prioritize and start tracking that. Don't create big tasks that are measured in percentages (frombulating the gizmobob is 42% done). Make small tasks that are either done or not done (0 or 1). Small tasks meaning measurable in hours, not days, let the people who will do the work make the estimates. Don't worry, this is not micromanaging, this is properly managing a project, and yes, it will take some of your time keeping track of all of this. There is also the question whether should you be doing this or should the product owner be doing this? Obviously the PO is not doing this, and you have a leadership position, so I would not hesitate too much.
  • chiefalchemist 8y ago
    Great point. Given what (little) we know it's fairly safe to say someone (important) on the dev team is looking to leave and will likely do so at the ultimate wrong time. I think aside from looking up the org chart, you have make sure your teams knows you're there for them. It's likely the have ideas for improving the process in the immediate, as well as the long term. Asking them is probably a wise thing to do.
• trm42 8y ago
  Sounds kind of familiar. We started a mvp/prototype that was handed to one guy without that much of a planning. That guy is really good coder but not a product owner/manager, documentor or planner. You see where this is going? This was about empowering team members with responsibility. Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version. The problems for us was we didn't know status of anything as it was always promised to be ready in 1-2 weeks but feature creep made it bigger and bigger. We tried to help with planning sessions etc but that wasn't enough to get the prototype back to track. As everybody got a bit too rosy picture of its status, our salesguy started selling the idea forward. The timing seemed to be right etc but we didn't have even proper deml version as the one guy chugged on with his waterfall ad hoc dev style... After our sales guy confirmed there's lot of demand for this proto and we got the first somewhat working version out and when the next steps were not really sane, we made an intervention which we felt we should've done four months earlier. First we had a team discussion and decision what should we do together for the situation and then we created concrete plan for the next steps we felt we needed to get first sane version out. Then we made this public to everybody. The funny thing with this intervention was that the guy who made the feature creep proto felt relieved after this. The biggrst reason why we were so reluctant to intervene was that this guy would get badly demotivated but he had chugged on so long he did get really stressed and frustrated with the situation but didn't know how to get help in the hole he had dug in. So my advice is to talk out loud and make things visible. Timelines, features bot yet implemented etc. Maybe a gant timeline etc. These helped us to get the project to a sane point shere to continue.
  • kimdotcom 8y ago
    So, have a plan?
  • BigJono 8y ago
    > Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version. This is interesting. Every example of scope creep I've run into has been a case of too many cooks in the kitchen, or an over-zealous "thinker" (as opposed to a "doer"). If I want to avoid scope creep I limit the scope of the project to as few people as possible and get them as close to the users/market as possible. It sounds more to me like everyone did get their two cents in, but not in the correct way, and this lone developer was formulating the requirements based on way too many informal channels rather than one structured one.
• jasonm23 8y ago
  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 8y ago
    > 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?
    • tinco 8y ago
      The X axis would go from low risk+complexity to high risk+complexity, and the y axis from low biz+cus desirability to high biz+cus desirability. You are correct that the way you described wouldn't work.
      • blahblahblogger 8y ago
        Yes it seems like an item would be posted on an axis where theoretically the item could exist on both ends?
• ksec 8y ago
  I do not believe in blindness optimism which seems to be the way things work in Silicon Valley. But That doesn't mean you are not going to achieve it, but you have to strategically plan your features / function. A Project or Product are never really finished. There is always a long tail of things to do or remake. In case of the goal being so far ahead, pick three ( or may be just one depending on teams size, but no more then three ) things / function / product features, that it MUST work, start sprinting towards those goals. Make them sound as easy as possible. Make a deadline that they know they could sprint to. My experience has taught me, may be only 1 out of every 10 or 100 person can see the bigger picture. Human are not very good at broad perspective, that is why you must set small enough goals, that is mentally easy to comprehend, and therefore mentally easy to achieve with hard work, but not impossible, damaging morale. Most of the time, ( if not all the time ), once you prioritise those goals and reach within 80%, of what looks nearly finished project. This is a good time to talk to direct manager, because your last 20% of project will likely take the same amount of time as your first 80%. The higher management will hopefully, having seen the good enough 80% work, decide on which direction to go next. ( Which is another broader set of view on how to jiggle product / project / business/ operation / expenses priorities. )
• patan2 8y ago
  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.
  • Double_a_92 8y ago
    That's rather stressful for your team members though. Especially if the tasks are too much outside of everyones comfort zone. At best you will get hacky code that only properly works on first sight, just so they fullfil their task. It's like telling you that you have 3 months to achieve world peace, otherwise all the wars are your fault.
  • muzani 8y ago
    3 months is actually enough time to add people, especially if there's the possibility of a deadline extension. I normally consider 1 month the break even point. You do have to schedule training and all. Another way to look at it is that programmers hate death marches. Projects like this could lose people, and sometimes it's good to have some backup.
    • jcadam 8y ago
      Depends on the project. In aerospace (my industry), 3 months is not enough time. There's so much process and bureaucracy that everything moves very slowly. At 3 months, the new person may be just starting to look at source code. But of course, they still try it anyway. Lead: "We're in serious danger of missing our delivery date in 6 months." Suit: "Egads! Here, have 5 new grads with no experience for your team, get it done!"
  • yitchelle 8y ago
    Instead of not adding new members, I would suggest to add new members to close out the current team's lack of knowledge. The OP indicated that the team is outside of their comfort zone, I recommend to add an expert domain into the team as a mentor to close out the gap.
• boffinism 8y ago
  > we're not going to make the release > At what point should I start sounding the alarm? Immediately. IMMEDIATELY
  • tobyhinloopen 8y ago
    This was also my thought, hah :)
  • arendtio 8y ago
    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 8y ago
    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.
• mikekchar 8y ago
  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.
  • tobyhinloopen 8y ago
    > 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
• deleted 8y ago
  [deleted]
• kimdotcom 8y ago
  If it is written in JS, port it to Elixir. Otherwise, rewrite it in JS.
  • tobyhinloopen 8y ago
    Something > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > JS > Elixir > OutOfTimeException
    • kimdotcom 8y ago
      I think this is funny. Well done.
• benbristow 8y ago
  Split the project into sub-tasks and order them on a kanban board (Physical/Digital). Figure out which sub-tasks are most important and work through them. Assign them to people if need be. Take time out to do a standups around this board at the start/end of the day to figure out where you're at. Higher ups will be able to see this too and probably will appreciate the clarity. Even if you don't hit your full deadlines you'll have a more complete 'product' this way
• d--b 8y ago
  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
  • OliverJones 8y ago
    Exactly. Managers manage many things, including expectations. Make sure your manager and you are on the same page about schedules. Then let her do her job while you do yours. If your manager decides to blame you, rather than defend you and your team, it's resume time.
    • arethuza 8y ago
      Managing up is the most important thing a project manager can do ("shit umbrella vs shit funnel") - if they haven't been communicating the actual status of the project then they haven't been doing their job. If they don't know the actual status of the project then they haven't been doing their job either.
• mudiaga 8y ago
  You should have the talk with the product owner already. It's always better to be open about these things early. Discuss the possibiltiy of completing only the core features first.
• LoSboccacc 8y ago
  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.
• expertentipp 8y ago
  lawyer up, hit the gym On a serious side though, perhaps release a beta version in the following days with the current state of the service/product? Maybe even give the customers a preview? That would be a cold shower and wakeup call for all stakeholders.
• raverbashing 8y ago
  > At what point should I start sounding the alarm? Last week ideally. But now is fine. > give it a couple of weeks and see if the team picks up pace They won't if nothing changes. What do you mean by "outside of their comfort zone"? Is it a technology that people don't master yet? Do you have experts on that technology already on the team?
• Double_a_92 8y ago
  1) Tell the manager that "sold" it to the customers 2) Create a clear list of planned features with him (if you haven't already) 3) Priorize the features. I.e. find out the ones that where really promised to the customers (the manager knows). Usually it's just 1-2 key features that sell the product. 4) Focus just on those and code properly. Especially if you are doing a rewrite / modernization. What's the point of having a new product, that is hacked spaghetti code from the beginning?
• crististm 8y ago
  By the way: it's your job to buffer the pressure from upper management towards the team so they can see you have a backbone and to maintain morale. They are _your_ team.
• egeozcan 8y ago
  Cut features until it'd make the deadline, even weeks before the deadline. Have something to show. That's my only advice.
• icedchai 8y ago
  This is basically normal. Virtually every software project, except incredibly simple ones, has delays. People, even experienced ones, are very, very bad at estimating. Just meet with your boss and manager and explain the issues, sooner than later. If the product owner is still in denial, well, you told them... They have to face reality.
• snarfy 8y ago
  Who said it was going to be done in 3 months? Where did that unrealistic number come from?
• ljw1001 8y ago
  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.
  • thisisit 8y ago
    > 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?
  • Talyen42 8y ago
    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.
• skate22 8y ago
  If you're not on schedule, tell your PO. We estimate tasks to be done as if they were done by even the least experienced teamate. My PO would rather cut a few features and hit the deadline than deliver nothing because we wern't conservative in our estimates. It's a lot easier to plan for the worst early & hope for the best
• ujjain 8y ago
  Keep morale of the team high. Nothing worse than feeling to be on a failing project with lots of pressure to make unrealistic deadlines.
• _dan 8y ago
  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.
• al2o3cr 8y ago
  Lots of good advice on prioritization & managing expectations already, but here's one part that jumped out that hasn't seen much attention: > The team is great, it's just that the work is way outside their comfort zone. This reads to me like the team doing the implementation literally couldn't have estimated this work at the start. Who in the company committed your team to deliver a fixed set of features in a fixed timeframe with new technology?
• lscharen 8y ago
  One thing to do is to push the knowledge and acceptance of the situation up the management chain, especially to the non-believing Product Owner, lest the Thermocline of Truth[1] be revealed in two months and three weeks. 1. http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-themocline-of-truth/ http://brucefwebster.com/2008/04/15/the-wetware-crisis-the-t...
• chiefalchemist 8y ago
  Lots of great input. I'm still going through them all. That said, I would update my resume and reach out to my network. If this ends badly you want to be prepared.
• trh88 8y ago
  Best advice I have ever been given (in project management generally) is that it does sometimes go wrong, and when it goes wrong: STOP. RESET. CONTINUE.
• tmaly 8y ago
  The project will either fail or be severely scaled back to launch a minimal version of what was promised. I would hedge bets and try to figure out what the crucial features of that minimal version are. Focus on those, and build extensive testing that will help you when its crunch time. I did just that and was able to launch a project.
• ajcodez 8y ago
  I would send upbeat emails at every milestone listing the accomplishments of your team. Throw in some tech speak to impress non tech people. By the time the deadline comes and passes anyone on the email thread will know how much your team has done and will trust you to finish the job. I would also assign tasks or busy work as the deadline approaches to anyone who is waiting on you to launch. Have them beta testing, etc. People are a lot more patient when they have things to do and a lot less patient when they are just waiting for you to finish already.
• hallihax 8y ago
  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 8y ago
    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
• ochrist 8y ago
  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 8y ago
    The best advice in the comments. You breakup the project into sprints and let the product owner choose priority.
• sethammons 8y ago
  Break things up into milestones (preferably deliverables). Put team-agreed-upon date estimates. Provide regular updates to higher-ups on the status (maybe every week or two). Try green, yellow, red as classifiers on each milestone. Identify potential issues and/or blockers. Communicate those and what your team is doing to mitigate them. Document what does get achieved, and communicate that too. Come up with contingencies and compromises, such as "if we remove freature x, we could shave off 5 days, or if we have extra help testing features a, b, and c, we might be able to push up milestone y. At least, at my org, these are all considered appropriate.
• z29LiTp5qUC30n 8y ago
  Well there is only one way a modernization project could have gotten into that position; You were doing a rewrite. A modernization project is only a modernization project if it is incremental by design and you have frequent releases (minimally monthly). Throw out the flag onto the field and get the train stopped before you end up causing the entire group to be fired.
• jezclaremurugan 8y ago
  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.
• mathattack 8y ago
  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.
• ddebernardy 8y ago
  There are hints in your question that you might be undergoing some major rewrite/refactoring across the board. If so, that has always failed insofar as I've experienced or seen experienced it. FWIW a better approach would have been to break the entire thing down into smaller, more immediately achievable milestones. Ideally do so alongside enough exciting new stuff to keep your developers' morale high - be weary that some might already have low morale if they're noticing that the project they're working on is going nowhere. At any rate, the time to bring up the problem is likely now. Have a candid discussion with your team. Explain what's going on; collect data points you might be less aware of and new ideas as you do. Sketch out a brief but equally candid status of your current situation (in writing) to let your manager and the product owner in the loop, along with an outline of next steps get things back on track.
• ransom1538 8y ago
  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.
• deleted 8y ago
  [deleted]
• ryanolsonx 8y ago
  Ruby on rails. /trolling
• kodablah 8y ago
  I am no lead, and never will be with my attitude towards these things. But sound the alarm immediately, realize that the business doesn't care because they have deadlines, watch it burn, then leave such a toxic environment. The order of the last two steps is interchangeable. Sadly, everyone thinks removing yourself from bad environments, especially as a lead, is selfish as though the company isn't. Also, many assume leaving is impossible/difficult, but in our industry at this time, that's rarely true.
• adrianmsmith 8y ago
  In addition to the other advice here, regarding how to handle this politically and from a communication perspective, I think you need to quantify to what extent you're not going to make the release. - You need to write down all the things that need to be done, the granularity of task should be between half a day and two days. (Anything larger than 2 days will be a task like "refactor this system" that hasn't been though through enough, and thus likely to be completely wrong.) Do this in a meeting with all your team members, they will be telling you what they foresee they need to do. - If you can't estimate things, because e.g. the system design hasn't even been started yet for those things, you need to design them, at least on a very high level. So that you know, at least to some extent, how long you think they're going to take. - Write down estimates for the aforementioned tasks, in person-days, by getting your team members to estimate these tasks. - Ideally use some kind of task planning system such as MS Project, LiquidPlanner, manuscript.com or some JIRA plug-ins that can handle this sort of stuff. But even a Google Spreadsheet shared between your colleagues will be better than nothing. - Now you'll know an end date. How far out is it? 4 months rather than 3? 12 months rather than 3? That makes a difference. If you're going to be late, you management may wish to give you an extension. If the project's going to take another year, management may wish to cancel or change the requirements significantly. You have to provide them with the information to enable them to make that choice. - If it's decided to continue, then update that spreadsheet all the time. Get your team members to update it, and if they don't do that, then talk to them every few days and get them to tell you what they still need to do. Focus only on the future: remove tasks when they're done, add new tasks as they arise, change estimates on tasks as they're partially completed. So even if you decide to continue, maybe in one month it becomes apparent you haven't made as much progress as you'd like, or there have been unforeseen difficulties resulting in more tasks. Know if it's going off track again as soon as possible. Estimate will be wrong. Things always take longer. This is a minimum bound. But if your spreadsheet says you need another 12 months on a project that only has 3 months to go, you can be sure that it won't be done in e.g. 2 months, that's useful information to have.
• kps 8y ago
  The Mythical Man-Month, Fred Brooks, 19fucking75. What has been done is what will be done.
• deleted 8y ago
  [deleted]
• jonbarker 8y ago
  A good customer success team can patch sales up that might have promised features that won't be to spec. But that bandaid only lasts for a short time.
• dylanhassinger 8y ago
  Read "Getting Real" http://gettingreal.37signals.com/ http://gettingreal.37signals.com/ Yes sound the alarm. Your heading towards a a million dollar failure. Instead define a bare minimum feature set for 1 user role, build a mvp with that minimal feature set and get it into the hands of users then start adding more
• iliasku 8y ago
  just move to sales / marketing. then you'll be the one making unrealistic promises that noone blames you for when they don't get realised
• loydb 8y ago
  I'm firmly in the 'raise the issue with your boss immediately, and let him own the fire alarm decision' camp.
• feyn 8y ago
  FWIW https://neilonsoftware.com/2018/07/12/my-response-to-as-a-team-lead-how-to-handle-project-going-off-the-rails/ https://neilonsoftware.com/2018/07/12/my-response-to-as-a-te...
• deleted 8y ago
  [deleted]
• bsvalley 8y ago
  Setup a meeting with the dev team (only). Go over all the main features required for this release, ideally, they should already be in a form of "user stories". Depends if you're in an Agile env or not... in 2018, I hope you guys are. Then during this meeting, run a deeper and more detailed estimate for each user story. How long would it take, what work has to be done and is it depending on any other team or future work? etc. When you get a better understanding and know how off the original estimation/deadline is (compared to this new one), setup another meeting with your PO and your manager to share this information. Obviously you will need material for this meeting. As a lead, that's your job to create that material (slides, etc..) That's it. As a lead, your job stops here. Any other decisions will have to be made by your PO or manager. Your role is to share that knowledge because these 2 don't have a clue about the actual work that has to be done down to the lines of code. Good luck (you're not doing anything wrong at the moment, just bubble up the information and let them do their job).
• deleted 8y ago
  [deleted]
• shove 8y ago
  What's funny is, you can armchair quarterback this all you want and it likely won't matter one bit. Toxic organizations gonna be toxic, and healthy organizations (probably) gonna be healthy. From outside, it's nearly impossible to tell which is which and by the time the OP is sure, it'll likely be too late to make any difference. Maybe they make you the hero, maybe they make you the fall-guy. Very little you can do to influence that. Focus on the work.
• lmeyerov 8y ago
  Yep. Folks know (or you have bigger problems). Leadership doesn't want FUD nor misleading positivity, they want constructive & predictable leadership... even if late. The conversation they want is, "As the leader, the risk X has now hit, and to avoid underlying Y happening again and achieving predictability goals Z, I'm leaning to A or B on this timeline with those key delivery+derisking milestones. To get there, can you help with resource/negotiation/decision C, and what are your thoughts on alternatives?"
• ChuckMcM 8y ago
  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).
• sudouser 8y ago
  my advice: communicate, over-communicate.
• totalrobe 8y ago
  Maybe your org is different, but the way your question is worded you are a lead developer, not a project manager. I'm a believer in flat orgs to some extent, but as a product owner/pm myself, this communication should be coming from the dev project manager, along with revised timeline and/or mitigation plan. The only alarm should be to your project manager, and in the form of objective analysis of the number of items completed against the plan.
  • arwineap 8y ago
    To add to this, maybe your PM can help by getting scope reduced, or additional QA resources. If they suggest more dev resources, be wary; that almost never speeds up project completion
• bluGill 8y ago
  Others have hit on this (so read the discussion: they are right - even when they seem to contradict each other), but I'll say it again because I think it is critical. You need to find the real needs of the real users and customers. You need these in priority order. Perfect answers are not required, just good enough answers. Now get your team focusing on getting things done in priority order. When your 3 months are up you can then say "we didn't get everything, but we think it is good enough". If you cannot get someone else to tell you priority, then start asking questions until you can come up with an answer. Sometimes you have to make a decision and hope you are close enough. Sometimes you will find other people (marketing, sales, your boss) who will help. An incomplete team that recognizes that things might not be perfect but they can influence one where the imperfections are is better then going alone, but go alone if you must. Note that customers and users are not always the same! If it is a customer need you can fake it as it won't be used, so make this look good, but make it obviously useless to users. If it is a user need it needs to work right, but it doesn't need to look as good since the customer has already bought it. Of course for release two you have feedback on what needs to be fixed.
• debt 8y ago
  "The business has been selling the new version.." But it's not built yet? IANAL, but make sure they're doing this correctly. There's a fine line between selling and outright lying aka fraud especially if the "new version" doesn't exist. Serious question, are there any adults around that can help your team?
• larrywright 8y ago
  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.
• scarface74 8y ago
  I wish I had some good takeaways from my first and only experience as a dev lead. The Good: - I came in with a blank slate. They had no source control, no CI/CD, and two "database developers" using an ancient platform with only passing knowledge of any modern language - C#. I was able to implement best practices and teach them how to code in C#. - The developers were eager to learn and were smart. The Bad - The company moved the entire project to AWS but to get anything provisioned I had to go through both my manager, the net ops people, a bunch of hired consultants, and an outsourced cloud management company. I never did get access to anything outside of some EC2 instances. - None of the people involved knew anything about AWS besides how to translate an on prem network to AWS and then wondered why it costed more. - I had a budget to hire, but only contractors. All of the best developers wanted a full time job with benefits. I never got the cream of the crop. - When the company was acquired, they decided that they didn't "want to be a software company" and wanted to outsource everything. They did however want me to lead two more projects to completion. I stayed long enough to finish phase 1, but it wasn't the best implemented thing in the world. It was architecturally sound, but didn't leverage anything AWS provided. - Everyone above me was jockeying for position at the newly merged company and didn't make development a priority. My solution: - I left for a job that pays slightly more where from day one I was given AWS admin access (yes I had the qualifications and experience). I'm now "just" a Senior Software Engineer but I am nowhere near as hamstrung when it comes to getting things done.
• wsy 8y ago
  In addition to all the good advice already given: this question has (at least) three different dimensions: - what would be best for your company? - what would be best for your team? - what would be best for you? Try to come up with answers for these questions separately. In particular, find out what is important for you personally (making a career, gain trust with your team, being open and honest, etc.). Identify the communication strategy which optimizes the outcome for you, your team, and your company.
• pdfernhout 8y ago
  As others have said, key at this point is going to be to prioritize in relation to business needs. As hard as that all will be, the process will only get more difficult the longer you wait. I'd also suggest one thing you prioritize personally for yourself whatever happens is eight hours of sleep every night. :-) As other have also said, you're also going to have to tailor the way you present the message about the facts (i.e. the "alarm") to your current organization's culture and your specific situation in it. You'll need to keep in mind your own talents/resources and current limitations in developing a message or plan (see also "Dunning–Kruger effect" for risks on that). Talents/resources and limitations include your own ability to present a message and what help you can rely on from the rest of the organization to develop a message and present it based on what your coworkers, manager, and management chain value. If you eventually want to reflect on the larger issues that may have gotten you to this unfortunate situation and what your company can do better in the mid-term and long-term, here is a reading list I put together that includes multiple books on software engineering management as well as broader surrounding issues -- including a great book by Matthew Walker on the importance of adequate good sleep for everyone in an organization: https://github.com/pdfernhout/High-Performance-Organizations-Reading-List https://github.com/pdfernhout/High-Performance-Organizations... One item from there: "Why Deadlines Need to Drop Dead" by Eric Elliott https://medium.com/javascript-scene/why-deadlines-need-to-drop-dead-321739ae6be1 https://medium.com/javascript-scene/why-deadlines-need-to-dr... "Deadlines are incredibly destructive to team productivity and morale. The #1 challenge software developers face is unrealistic expectations. Can we motivate & push without arbitrary deadlines? You can lead teams without deadlines. You can still deliver code quickly. You can still ship in time for Christmas. But you’ll be dealing with a different management framework. One that puts the deadline pressure on product managers rather than developers. ... The point here is that instead of trying to build out the CEO’s ideal vision of the product you’re bringing to market, you build out a beautiful stepping stone on the way towards that vision. In place of arbitrary deadlines, you deliver consistent, steady progress." Eric Elliott advocates for the Marketing department creating each hype cycle for what is already finished and tested.
• sajagi 8y ago
  It all depends on what kind of company are you in, what kind of people are your superiors, etc. How much politics and backstage dealing is involved? In an ideal situation I would say call be honest and tell the stakeholders your view. On the other hand, from my corporate experience, it's not always the best course of action. See - as lwj1001 already said - some companies play sort of meta-game, where certain things are known but never said out loud. If you are in a position to change the environment - great! (But this is not likely the best opportunity to do so). Otherwise... I would still say your opinion to those who need to be informed, or even better - write them an email. The reason is - you might have to cover your ass in the near future. The worst that can happen is that everyone assume everyone know yet there is someone who doesn't.
• svilen_dobrev 8y ago
  whatever u do, beware: HR dept is there to protect the company from its employees. NOT the other way around - regardless how much anyone fanfares it..
• dodgyb 8y ago
  Be prepared for the questions that you will be asked when the alarm is raised. Q1. Why late? Work is 'outside of comfort zone', thus accurate estimates are impossible. Q2. When will it be ready? Scope, timescale and quality are interdependent. Ask 'the business' which two are most important to them. The remaining item will need to be revised. My recommendation would be to curtail scope and deliver the rest in phase 2. If they say timescale can be extended the revise estimates based on current velocity, i.e. if you are 30% behind where you expected, add 30% to all outstanding work items. If quality is cut, make sure they are aware of the additional support and maintenance costs that will be incurred. Either way, do as rinka_singh says and get the PO/PM to establish a risk log accessible to all. I would add that each risk should be assigned to someone who is responsible for tracking it. Review the log each week. Raise the alarm now because there will be dependencies, and you are probably not aware of all of them. I would not be worried about how the alarm is percieved, if your intentions are to steer 'the business' away from a cliff it will be recognized.
• gt2 8y ago
  Cut/Delay a few features so the thing can be launched?