5 ms·

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability. This worked well and was driven by his understanding that most of his effort needed to be focused on identifying and mitigating delivery risk. Most often the key risks lay in trying to estimate the level of effort required to develop key new functionality when all involved had limited prior experience in developing similar functionality. In those cases funding a short time bounded study to explore the technologies involved and figure out the art of the possible reaped huge rewards downstream. If only all customers were that enlightened!

maxxxxx 8y ago
For stuff that's new I always tell management to give us a certain amount of time (weeks or even months) to figure out the major unknowns. After that has been done they can get a reasonable estimate or cancel, whatever they want to do. This seems to be the only realistic way to go about things.
- Benjammer 8y ago
  I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called "Technical Discovery," with clear goals and a clear time-box.
  - maxxxxx 8y ago
    In my company everybody goes over spec sheets and endless meetings to determine the right approach instead of just sitting down and using the time to try things out. A big problem is that there is also no culture of being allowed to say that an experiment has failed and we'll either cancel or try something else.
  - alasdair_ 8y ago
    Hasn't this been a core component of doing "agile" in any meaningful way since the beginning? Example: "architectural spikes" in eXtreme Programming: http://www.extremeprogramming.org/rules/spike.html http://www.extremeprogramming.org/rules/spike.html
    - maxxxxx 8y ago
      Yes, this is how Agile should work but rarely gets done from what I have seen.
    - aninhumer 8y ago
      One thing I've been thinking lately is that this should be baked into the process for every unit of work, not just those people expect to be difficult. Instead of estimating by guessing based on reading the requirements, work on an issue for say an hour or so and then estimate it. It still wouldn't be perfect, but I think this would catch a lot of cases where, for example, a seemingly simple feature ends up requiring an extensive model change. It would also do a much better job of shaking out cases where the requirements aren't as clear as you thought when you start trying to code it.
    - lazyasciiart 8y ago
      Oh, you'd think so. Then you might be unlucky enough to work with some 'senior programmers' who have been 'doing Agile for years' and are able to convince the manager that a spike that doesn't result in code that will go to production is a waste of time. I never worked out whether that was malice or stupidity.
    - gaius 8y ago
      The irony being that XP and the like are only suited to cookie-cutter, commoditised work that is essentially risk-free anyway
      - TheCoelacanth 8y ago
        I couldn't disagree with this statement more. On projects that are breaking new ground it is even more important to follow XP practices like getting frequent feedback from customers, taking the simplest solution that could possibly work to avoid overengineering before you actually understand the problem, to embrace change because your original understanding of the problem probably isn't right. There also is plenty of risk involved in cookie-cutter commodity work. Those kinds of projects fail all the time.
eagsalazar2 8y ago
At my company projects always start with P1 - research, and P2 - plumbing which are exactly what they sound like. The idea being to uncover and confront risk/unknowns as early as possible before some massive misguided investment has been made.
- flud 8y ago
  What's the plumbing part? And what scale are the projects, ballpark?
  - eagsalazar2 8y ago
    Plumbing is basic project setup, CI, testing, etc but also all core functionality and any technically questionable bits like integrations with client APIs that are frequently not what is advertised. Research is always conducted by one of our "CTO"s (partners who have > 10yrs experience). Projects vary at the low end from 2 people, 2 months up to 5-7 people for a year or longer. We do smaller stuff like prototypes also, usually as a first step in a longer series of releases. We are local in SF and frequently work in client offices. Budgets are between $100K - $1M.
wpietri 8y ago
Yeah, I love it when customers can work like that. The way I often explain it is that a product manager can buy software, but they can also buy information. Information like, "Is X possible?" or "What would it cost to build Y?" or "What would the performance be if we switched to Z?". Once they catch on to that, it can be great.
- IshKebab 8y ago
  That's a really good way of putting it.
- hardwaresofton 8y ago
  This reminds me of a article on HN from earlier -- this sounds like the core competency of management consulting: https://www.cbinsights.com/research/disrupting-management-consulting/ https://www.cbinsights.com/research/disrupting-management-co... One of companies mentioned, Gerson Lehrman Group (GLG), literally sells the time of vetted experts.
zhdc1 8y ago
Yes. Yes. Yes. Technical discovery is baked into traditional project management (e.g., civil engineering) in a way that continues to surprised me as a former IT project manager. There is a culture of investigation and research, such as materials research, proof of concept development, and needs-driven public-private academic research in other technical fields that IT project managers just don't get exposed to. For instance, engineers planning a drainage project have a very good idea of how long a particular type of pipe will last before it needs to be replaced. They also have the tools/software/training needed to estimate how local stresses affect functionality and lifespan, and they're expected to use this information - even if the lifespan of the project exceeds their expected tenure. IT PMs can't say the same thing about their infrastructure - who knows how long AWS or Azure will be around, for instance, or how long a local server blade or piece of network equipment from (x) company will actually last. When it comes to software development, the prevailing attitude is 'I want (x) by (y) for (z)', without having any justifiable basis for (x), (y), or (z).
- kitd 8y ago
  I think this is why it is very helpful to use tried and tested tools and tech stacks in an IT project, those with large ecosystems of libraries and communities of people who have solved similar problems in the real world in the past. The "problem solving" risk is much lower as a result.
  - erikb 8y ago
    At the same time the board will finance the fancy new buzz words though. So combining both requirements I would say the art is in trying to use tried and tested technology to fulfill buzzwords.
- jarl-ragnar 8y ago
  I'm now head of product development at a different company and one of the key activities I instantiated was using internal R&D funding to conduct technical discovery and remove, where possible, software development of new functionality from the critical path of project delivery. I'm convinced IT project management could learn a lot from civil engineering project management.
flud 8y ago
That sounds pretty smart. How did these de-risking studies usually consist of?

maxxxxx 8y ago

For stuff that's new I always tell management to give us a certain amount of time (weeks or even months) to figure out the major unknowns. After that has been done they can get a reasonable estimate or cancel, whatever they want to do. This seems to be the only realistic way to go about things.

Benjammer 8y ago
I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called "Technical Discovery," with clear goals and a clear time-box.
- maxxxxx 8y ago
  In my company everybody goes over spec sheets and endless meetings to determine the right approach instead of just sitting down and using the time to try things out. A big problem is that there is also no culture of being allowed to say that an experiment has failed and we'll either cancel or try something else.
- alasdair_ 8y ago
  Hasn't this been a core component of doing "agile" in any meaningful way since the beginning? Example: "architectural spikes" in eXtreme Programming: http://www.extremeprogramming.org/rules/spike.html http://www.extremeprogramming.org/rules/spike.html
  - maxxxxx 8y ago
    Yes, this is how Agile should work but rarely gets done from what I have seen.
  - aninhumer 8y ago
    One thing I've been thinking lately is that this should be baked into the process for every unit of work, not just those people expect to be difficult. Instead of estimating by guessing based on reading the requirements, work on an issue for say an hour or so and then estimate it. It still wouldn't be perfect, but I think this would catch a lot of cases where, for example, a seemingly simple feature ends up requiring an extensive model change. It would also do a much better job of shaking out cases where the requirements aren't as clear as you thought when you start trying to code it.
  - lazyasciiart 8y ago
    Oh, you'd think so. Then you might be unlucky enough to work with some 'senior programmers' who have been 'doing Agile for years' and are able to convince the manager that a spike that doesn't result in code that will go to production is a waste of time. I never worked out whether that was malice or stupidity.
  - gaius 8y ago
    The irony being that XP and the like are only suited to cookie-cutter, commoditised work that is essentially risk-free anyway
    - TheCoelacanth 8y ago
      I couldn't disagree with this statement more. On projects that are breaking new ground it is even more important to follow XP practices like getting frequent feedback from customers, taking the simplest solution that could possibly work to avoid overengineering before you actually understand the problem, to embrace change because your original understanding of the problem probably isn't right. There also is plenty of risk involved in cookie-cutter commodity work. Those kinds of projects fail all the time.

eagsalazar2 8y ago

At my company projects always start with P1 - research, and P2 - plumbing which are exactly what they sound like. The idea being to uncover and confront risk/unknowns as early as possible before some massive misguided investment has been made.

flud 8y ago
What's the plumbing part? And what scale are the projects, ballpark?
- eagsalazar2 8y ago
  Plumbing is basic project setup, CI, testing, etc but also all core functionality and any technically questionable bits like integrations with client APIs that are frequently not what is advertised. Research is always conducted by one of our "CTO"s (partners who have > 10yrs experience). Projects vary at the low end from 2 people, 2 months up to 5-7 people for a year or longer. We do smaller stuff like prototypes also, usually as a first step in a longer series of releases. We are local in SF and frequently work in client offices. Budgets are between $100K - $1M.

wpietri 8y ago

Yeah, I love it when customers can work like that. The way I often explain it is that a product manager can buy software, but they can also buy information. Information like, "Is X possible?" or "What would it cost to build Y?" or "What would the performance be if we switched to Z?". Once they catch on to that, it can be great.

IshKebab 8y ago
That's a really good way of putting it.
hardwaresofton 8y ago
This reminds me of a article on HN from earlier -- this sounds like the core competency of management consulting: https://www.cbinsights.com/research/disrupting-management-consulting/ https://www.cbinsights.com/research/disrupting-management-co... One of companies mentioned, Gerson Lehrman Group (GLG), literally sells the time of vetted experts.

zhdc1 8y ago

Yes. Yes. Yes. Technical discovery is baked into traditional project management (e.g., civil engineering) in a way that continues to surprised me as a former IT project manager. There is a culture of investigation and research, such as materials research, proof of concept development, and needs-driven public-private academic research in other technical fields that IT project managers just don't get exposed to. For instance, engineers planning a drainage project have a very good idea of how long a particular type of pipe will last before it needs to be replaced. They also have the tools/software/training needed to estimate how local stresses affect functionality and lifespan, and they're expected to use this information - even if the lifespan of the project exceeds their expected tenure. IT PMs can't say the same thing about their infrastructure - who knows how long AWS or Azure will be around, for instance, or how long a local server blade or piece of network equipment from (x) company will actually last. When it comes to software development, the prevailing attitude is 'I want (x) by (y) for (z)', without having any justifiable basis for (x), (y), or (z).

kitd 8y ago
I think this is why it is very helpful to use tried and tested tools and tech stacks in an IT project, those with large ecosystems of libraries and communities of people who have solved similar problems in the real world in the past. The "problem solving" risk is much lower as a result.
- erikb 8y ago
  At the same time the board will finance the fancy new buzz words though. So combining both requirements I would say the art is in trying to use tried and tested technology to fulfill buzzwords.
jarl-ragnar 8y ago
I'm now head of product development at a different company and one of the key activities I instantiated was using internal R&D funding to conduct technical discovery and remove, where possible, software development of new functionality from the critical path of project delivery. I'm convinced IT project management could learn a lot from civil engineering project management.

flud 8y ago

That sounds pretty smart. How did these de-risking studies usually consist of?