3

After running a few projects that refresh technology rather than add functionality, I've noticed a few recurring themes:

  • Technology refresh projects are more likely to go over budget/schedule; projects that provide incremental new features are less likely to exceed budget & schedule estimates.
  • Development teams are more likely to underestimate technology refresh projects.
    • New functionality tends to have well-defined requirements.
    • Old functionality is always a journey of discovery, especially on widely deployed products with history of customer-driven fixes and enhancements.
    • A large part of this hidden legacy only comes out after the team has a chance to make serious headway with refactoring.

All of that makes early feasibility assessment and ROI analysis on such projects challenging.

I've tried two techniques to address this. One technique is to add a constant tax on top of team's estimates, but that can be crude and imprecise, since refactoring projects are not born equal. Another is to delay estimate and schedule projections until the team has spent reasonable effort flushing out the hidden costs. This does not always work though, since sometimes such reasonable effort in itself is expensive, and/or the business requires early prioritization.

I'd be interested in collective wisdom from people who've run such projects. How can I get get reasonable predictability when planning a technology refresh?

Improve this question
1
  • 1
    Your question has been lightly edited, primarily to remove the list-generating opinion poll. PMSE requires questions that at least admit the possibility of a canonical answer, rather than lists of lists. A question should seek to solve a problem, not explore a constellation of possibilities.
    – Todd A. Jacobs ♦
    Oct 31, 2016 at 17:12

2 Answers 2

Reset to default
2

I don't have enough experience to confirm or rebut this hypothesis. That said, if I were in the position, I would propose the minimum possible refactor project (kind of like my academic colleagues used to have the "least publishable unit") If I understand correctly, working from existing requirements involves discovering (through trial and error) a set of what might be called latent, unstated, cultural requirements (closely related to "tribal knowledge" and "Organizational Process Assets").

So let's charter a project to do the least imaginable technology refresh. That puts a team in place (and more importantly in communications) with the stakeholders who will suddenly reveal those new requirements. If we charter a 1 month project to do a trivial technology refresh. ("Everyone gets a new mouse"), that should provide us with a parameter that we can use to improve the accuracy of larger technology refresh projects.

I don't think the accuracy is going to improve by an order of magnitude. At best, I think this would do a better job of uncovering closet stakeholders (and or zombie stakeholders - you know the ones - you can't change this because Bob who retired 10 years ago and died 3 years ago... Bob set it up so you can only do this workflow from his desk and not on a Friday....)

Improve this answer
3
  • So, essentially a spike to discovery the MVP for the project charter?
    – Todd A. Jacobs ♦
    Oct 31, 2016 at 17:16
  • I think so, but I was trying to avoid the use of words that I'm not certified to use.
    – MCW
    Oct 31, 2016 at 17:18
  • This is definitely in the ballpark - tribal knowledge and zombie stakeholders are very good terms unique to this problem. My experience is that we usually uncover technical pitfalls that people built and masked over the years. Having a spike task is one way of dealing with it. I'll accept the answer, as it's close, and the question was open for a while.
    – RomanK
    Oct 31, 2016 at 18:03
1

In my observations working in this industry over the years, I do not opine that IT projects suffer from anything different than any other project in other domains. What I see is an industry specific pressure placed on IT projects that other domains have worked out. There is a significant pressure to low ball project price just to get the project selected. This begins long before any type of proposal request hits the street for IT vendors, and then the next pressure for a low ball price begins.

In the federal space here in the US, there is a push to get everything in at a firm fixed price, even for projects where the federal customer doesn't really even know what they want and will be "discovered" during the project. No other industry selling provider would ever sign up for a contract like that but IT vendors do it all the time. Can anyone imagine a building contractor signing up for a fixed price build to build a "house somewhere over here"?

Under estimating occurs in all projects because it is a human bias called optimism bias. But the other estimating methods help control that, e.g., using historical data, parametrics, Delphi Technique, etc. However, before using these proven methods, this pressure for pricing illusion needs to be resolved.

Improve this answer
12
  • 2
    signing up to build a house with an indeterminate number of bedrooms suitable for an indeterminate climate and adhering to an indeterminate set of regulations and appealing to an unknown taste. That's the federal government , transforming "Bring me a rock" into "Build me something and I'll tell you I don't like it when you're finished. Oh, and it has to conform to the Enterprise Architecture that we refuse to permit to be written, and must be Agile."
    – MCW
    Oct 31, 2016 at 13:55
  • 1
    @CodeGnome, if I could answer that question, I'd be wealthy and retired by now. In my firm, we have controls that are supposed to help with this but the proposal teams learn how to navigate around them and those controls also have pressure to not do what they are designed to do; instead, make an appearance of doing what it is supposed to do. I do not know the solution.
    – David Espina
    Oct 31, 2016 at 17:23
  • 1
    @DavidEspina It's this last sentence: "But the other estimating methods help control that. It would work in IT, too, if we actually used them." To me, that implied that you thought there was a concrete solution. Maybe if you edited it? I agree that there's currently no known solution; just mitigations, of which agile practices (among others) offer some options.
    – Todd A. Jacobs ♦
    Oct 31, 2016 at 17:49
  • 2
    The solution is not the estimating techniques--delphi method, 3-point, historical data, etc.--because that is not the issue plaguing IT. The issue is more about the pressure of creating a pricing illusion. The solution has to be around that pressure we are facing. I hope that makes sense.
    – David Espina
    Oct 31, 2016 at 17:53
  • 1
    Can you update the answer to address the issues discussed in these comments. I think "the pressure of pricing illusion" is too valuable to lose.
    – MCW
    Nov 1, 2016 at 15:47

Your Answer

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

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