How to speed up a passed-the-deadline project while maintaining credibility?

Question

The team I manage has been in the final pre-production push / bug-fixes stage at the end of the project for over a month now, while we allotted one week for these fixes (total project time was 2 months, are now at 3 months).

Due to external pressures, I have twice pushed for deployment with the outlook that this first iteration of the product doesn't need to be perfect, and both times deployment has failed and we had to rollback due to bugs and not being ready for the actual launch (which requires downtime and complicated database migrations).

I am "defending" my hurrying deployment (to my team) by explaining that I am OK with taking risks and "breaking things" in favor of relevance and ontime delivery, but they are not buying this. I feel that after two failed launches, I am losing/have lost credibility with my team, and they are not confident in my ability to decide to move forward, which is further slowing down the end of the project.

What is the right thing to do here?

Answer 1

It's not entirely clear to me what your situation is.

• Do your deployments succeed and get rejected by the stakeholders or do they fail in the first place?
• Either way you seem to be surprised by the outcome every time. This suggests that you have a poor understanding of either what is expected of your product or of what is required on a technical level to deploy.

Potential issue 1: Deployment is a crapshoot

You should have a sandbox environment where you can test deploy to your hearts content. You should be absolutely sure that when you deploy for real that it's going to work.

Potential issue 2: deal breaker bugs

You should be testing your product throughly enough that there shouldn't be any new major issue popping up when you present to the stakeholders. This could indicate that your code quality and maintainability is too poor or that you rely too much on manual tests and don't have the resources to fully run them. (I've worked in such a situation where we had several man-days worth of manual tests to run for each new release candidate). Neither of these issues is something you can fix without siginificant time investment but they are also not things you can afford to ignore.

You should also have a clear enough understanding of what your stakeholders consider deal breakers. In that case you need to have an honest and direct discussion about what they are willing to accept and how much time this is likely to require. It might be necessary to consider dropping some features that continue to give you troubles. It's a somewhat desperate solution and not in all cases easier than fixing it but I've had such a situation myself once. There was this one feature that I just couldn't get to work properly. So at some point we just postponed it to the next version.

Potential issue 3: inability to launch

You don't describe in what way you are unable to launch but whatever it is you need to get a handle on this. If you and your team don't understand what it takes to actually "ship" your product you need to stop and figure this out right now. It doesn't matter if the product itself is completely broken. A turd that you can ship is worth more than a jewel that you can't get to the customers.

Credibility

But I think the most important thing is that you step away from your risk-taking attitude. Project management is about managing risks not taking them. The attitude of "it doesn't have to be perfect let's just git r done" is usually a cop out that stems from the unwillingness to acknowledge risks and have tough discussions about what is realistic. You said you allotted one week for bug fixing. You don't allot time. Things are done when they are done. All you can do is be observant, sound the alarm bells early enough and sit down saying "this is not going well, what are our options". At this point the best thing you can do is admit you've been too optimistic and find some place where the expectations of your stakeholders overlap with what your team considers doable.

Answer 2

Putting out a product before its ready will always kill your reputation more than reporting a delay in that product's delivery. Both are hits to your reputation but a product you have to bring back in is far worse.

What are your go / no go criteria? The way you describe your decision to go seemed very ad hoc, like, "let's just do it now." If you never have established your go criteria, your checklist to deploy, then you did indeed fail and your loss in reputation is warranted.

To get it back, you and your team need to define what constitutes a go (your customer should also be involved in that), then you need to plan and execute the tasks, e.g., testing, to get the product to meet its criteria. Conduct your go / no go examination (with the customer), and based on that, decide to deliver or hold it back.

This is not rocket science but standard practice for thousands and thousands of products that are introduced to the market place daily. All products go out with some risk, some known, others unknown. But they all should have past their go criteria test. We do know that at times companies release a product with known no go deficiencies, but that usually leads to deaths, payouts, and expensive recalls.

Answer 3

For the immediate, stop pushing then ask the team how you can best enable them to improve quality to an acceptable level while doing whatever else is necessary for a successful deployment . . . then act accordingly. It may be that the team needs some trust, empowerment, and space to do their jobs. It may be that the team is lacking the knowledge, skills, etc needed. It may be that there was pushing throughout the effort and that cost of correcting the shortcuts that were taken has now been revealed.

Accept that you have failed and learn that treating quality as a result and not as the first-class citizen it needs to be will very frequently lead to this type of result. All involved should be educated regarding having an incremental process, the agile philosophy (it is not Agile^tm), having a test-first mentality to improve quality, and other proven software product development and management techniques.

What would be the result if one imposed deadlines on Monet or Vivaldi to create an unreasonable number of pieces within an unrealistic amount of time? What about the same for Einstein or Pasteur? Creative, cognitive, and complex work require time for experimentation, mistakes, and learning; creating software attempting to solve a problem or fulfill a desirement is creative, cognitive, and complex.

---

If it is the first iteration of the product then why is it that rolling back requires downtime and complicated database migrations?

---

I am "defending" my hurrying deployment (to my team) by explaining that I am OK with taking risks and "breaking things" in favor of relevance and ontime delivery, but they are not buying this.

The deadline is often the main focus instead of the craftsmanship of the product. Good craftsmen want to feel proud of what they have created and accomplished. That is possibly weighing on the team; it should be weighing on you as well. It may also be, or at least appear to be, that saving face for yourself (first via deadline, now via rushing) is more important than the the team and its values, concerns, and the result of how others perceive them.

Answer 4

I agree with other Answers posted on this Question, but none of them have answered the actual question in your title - namely, how to speed up the project (without harming your personal credibility). While this does seem somewhat of an XY problem, for this Answer I will take in good faith that this (and your personal credibility) really are your #1 (and #2) concerns - above such 'petty' concerns as quality or delivering value.

I can think of only one possible approach for this. Cut out scope.

Are you familiar with the concept of a minimum viable product (MVP)? Have you created one for your first iteration? Are you sure?

On an earlier project for which I was a Scrum Master/Developer, there were these two particular features. One was requested by a single user, and pushed forward by the boss as a 'must have'. The other was, as far as I can tell, requested by no one, but was also pushed through by the boss as a 'must have'. Both of these were also extremely complex, especially together, and interacted with the entire system.

Even after the features were coded in, we still pushed to remove them, purely because doing so would vastly simplify the system, thereby making any other work much easier/faster.

But instead, we went live with both features. And, years later, still no one actually uses them. Users actually complained about how one of these 'must have' features made the product too complicated and provided no value.

Removing functionalities that have already been coded has an initial cost, but may save you time in the long run simply due to reducing complexity. The only way to determine if you actually have such a feature, though, is to ask your developers. Essentially, ask them, 'are there any features that, including the extra time to take out and the reduced time to test, removing them would speed up the project?'

You then need to decide, for each feature the developers bring up, whether or not that feature is part of your MVP. If it's not - if it can be included in a later iteration (or never) and still have the first iteration be deemed acceptable - then cut the feature out of your first release.