4

My project has to deliver middleware components that will support a large, complex system development spanning multiple phases. My phase is due to implement in 6 weeks, with future phases being implemented in 6 months and 12 months from now.

Most of my work is well on track, but we have one component that we are just starting to put in place. We know what is needed to support the current phase, and are confident in our plans to deliver that. However, we don't have a clear view of how the future development phases will be implemented, and so we have not been able to plan our implementation with the future phases in mind. Carrying out the necessary analysis would cost us a couple of weeks, which would delay the overall implementation of the current phase by a week overall.

My question is this: should I opt for the quick implementation that fully meets the current requirement and meets current targets, but does not guarantee an easy future implementation, or should I request a delay to the project, with potential (but unproven) future benefits through avoidance of rework?

We are using a waterfall-based approach, rather than agile, and the technology is relatively new to the organisation. Does this make a difference to your answer?

Improve this question
3
  • Can you please elaborate on what is your role in this project and what will happen in 6 months and 12 months from now on?
    – CodeWorks
    Commented Apr 18, 2012 at 19:10
  • I am the Project Manager for the infrastructure components, which include middleware. Development is handled by a separate PM. We both report into a Programme Manager. The design was carried out by yet another group, and I (and the development manager) were given designs to implement. It is only now that we are beginning to understand the gaps in the design.
    – Iain9688
    Commented Apr 18, 2012 at 19:13
  • In 6 and 12 months, further phases of application code will be implemented, layered onto our middleware. My team will deploy the code onto the middleware, and this could include backing out code that is no longer needed, as well as adding the new code. We can make it easy to do this in future if we spend more time up front analysing the future plans, or we can go with what we know know, and hope that the changes (which include web content that may have been changed by the business as well as by the developers) are easily identifiable and not horribly difficult to back out.
    – Iain9688
    Commented Apr 18, 2012 at 19:19

7 Answers 7

Reset to default
3

Unless you have some indication that the work you do now may cause serious issues down the line, finish your scope now. There is too much uncertainty with which to cope trying to figure out what may happen in the future. Finish it, then get to work on the next stage.

Improve this answer
1
  • +1 for moving on to a close. Again, like my comment in response to Zsolt's answer, I will wait a while before accepting any answer, as I sense that there could be a split in opinions here!
    – Iain9688
    Commented Apr 18, 2012 at 21:56
2

I would go for the long term solution. Even you aren't doing Agile you can do the "fail soon fail fast" approach. If you fail do deliver at the beginning there will be some heat from top, but at least you won't have to redo a quick solution. You can save some time and money. Usually, quick solution means dirty solution. Build a system right from the beginning and keep the technical debt low.

The additional 9.5 months should be enough to be on track after the first milestone, but it is definitely not enough to redo a quick solution.

Improve this answer
2
  • +1 for keeping the technical debt low. But I'm going to wait until I see some other views before I decide to accept any answer. Quick - yes, but dirty? - well, that depends on how you interpret dirty. I wouldn't bet against the technical guys guessing correctly even without the analysis, as they have a lot of experience and they will ultimately have to unpick and redo the work if they guess wrong.
    – Iain9688
    Commented Apr 18, 2012 at 21:54
  • +1 for looking long, failing fast, keeping the technical debt low.
    – jcmeloni
    Commented Apr 18, 2012 at 22:25
1

I would try to go for the long term win. Why? You mentioned that additional time for the analysis and a "better" implementation would cause a week delay. In comparison to 12 months this is very little. So it sounds to me like a small investment with potential big benefits.

But what is more important...

we don't have a clear view of how the future development phases will be implemented, and so we have not been able to plan our implementation with the future phases in mind

The analysis will give you the big picture. That means you'll understand the requirements better which is a great value for the project and for the team.

Improve this answer
1
  • +1 for pointing out that the variance is small in relation to the overall project duration. One thing though: even with the analysis, we will only have an indication of how the rest of the project is likely to pan out, and not an absolute guarantee, but I do agree that the bigger picture will bring us closer to the final model than the quick solution will achieve.
    – Iain9688
    Commented Apr 18, 2012 at 21:50
1

I have read your question quite a few times, and I would normally say that a long term win is a way forward, however, on this occasion I think that quick implementation that meets the current requirement is a right way forward. I'll try to justify this with the following:

  • You are not going to avoid re-work. It's a natural process of software development and you are unlikely to get it right the first time. If it was up to our technical director, then we would never release software.

  • What if you are wrong? As you have said, it's a first time that you are using a waterfall approach, so what are the chances that you will identify further improvements two months time? Will you request a further extension and re-work everything, or will you draw the line?

  • How are you going to justify a delay in deliverables to the business without proven future benefits?

  • Worst case scenario. What is the worst case scenario if you don't carry out the re-work?

  • Long term impact. What is a long term impact of not doing the "re-work"? In our company we are sometimes forced to cut corners, but then business pay tens of thousands for every minute the system is down.

  • 6 months is a very long time in system engineering. I think that in 6 months a lot will change, and there are chances that your re-work will require further re-work, or might not be needed at all.

Improve this answer
1

For me, you're attempting to make a decision that isn't yours to make.

You have your scope and it's approved, so the current correct path is to continue toward completion as planned.

But you've identified a potential issue that may adversely impact the end-result project down the line. Your correct course of action as a responsible PM is to bring this issue to the Owner/Sponsor and ask for direction. Explain it the same way you've explained it here - short-term vs long-term, possible (but unknown) ramifications, possible delays,etc.

Then let them make the decision on how you proceed. Their project, their money, their decision.

Improve this answer
4
  • +1 for reminding me that the ultimate decision lies with the client, and not with me. I would just add one thing, however: I will be expected to make a recommendation, and so it still remains valid to think about which option is better.
    – Iain9688
    Commented Apr 27, 2012 at 19:44
  • And that's fine. Recommendations are easier, especially when it's not your decision. :) And from your original question I think you already know which you'd recommend. ;)
    – Trevor K. Nelson
    Commented Apr 28, 2012 at 2:16
  • The question was asked when I was not sure which way to advise. I have now made my recommendation, which has been accepted, which is to acknowledge and monitor the risk, while sticking to the original plan. We have put in place a mechanism to mitigate the risk by bringing forward the analysis for the next phase and assigning this work to a very experienced designer who should be able to help us to avoid too much rework if we have made a mis-judgement. Was that what you thought I would do?
    – Iain9688
    Commented Apr 28, 2012 at 8:20
  • Yes. Kind of the best of both worlds. You get to keep working as planned, but you've made the Owners aware of the issue so it can be included in future decisions. Nice job!
    – Trevor K. Nelson
    Commented Apr 29, 2012 at 16:02
0

Well, I am aware that answering with questions may - at first - look not like an answer at all.

Nevertheless, you are making the decisions, and (as I understand) you are asking for additional insights which would allow you to make one:

  • How much will cost the delay? How easily can it be accepted?
  • What is your previous experience with this team with investments in code quality? Did it prove to be worth the effort? Did it meet the expectations?
  • What is the likelihood that you will be executing the future phases?
  • What will be the difference in technical debt if you consider both approaches?
  • What do you prefer: take a technical debt or financial one (reallocation of resources or resource time)?

And the other question is:

Do you really need to take such costly analysis?

Are there any other ways to make quicker, but still valuable assessment?

Improve this answer
0
0

I don't think Waterfall / Agile has bearing on this, but as PM's, we're are often critised for looking at the short term "Get it in ASAP!" solution.

So although I believe the last gent is correct in saying it's not a PM's decision to make but in your position I put both solutions with their pro's and cons to your sponsor and strongly back the long term solution.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.