5 ms·

It doesn't take the contradicting interests in to account. People in IT should really stop to pretend that they are the only smart people that know how to run a

by cateye 9y ago

It doesn't take the contradicting interests in to account. People in IT should really stop to pretend that they are the only smart people that know how to run a business. A cfo can easily understand the benefits of an organizational capability to continuously improve a core business asset. But he also understands the difference between capex and opex and needs to take decisions in order to achieve the strategic goals of the company. This strategy can or can not define software development (for a specific goal) as a core in house capability that gets an investment. This relates also heavily with the defined core business etc. Without understanding the long term strategy of a company, it does not make a lot of sense to come up with generic advice. The ceo and the management board do generally (almost intuitively) understand which activities will generate competitive advantage. If they are not in the silicon valley hype, this can mean that they can make a deliberate choice to invest in other things than software teams. Is it really that unthinkable that other things than software can bring value to a company? Do all companies need to act like Google or Facebook? >>for greater responsiveness and a higher benefits realization ratio, “product-mode” is a more effective way of working than projects. This is a sweeping statement. This could definitely lead to higher benefits and lower responsibility for the consulting company. That is almost for sure. But that doesn't mean that a short living project organization is a bad idea by default. The choice needs a much more substantial argument like the probability of a positive realization result (depending on the complexity and uniqueness of the software) versus risk if it does not get realized etc. If it can't be bought of the shelf, it can be outsourced or developed entirely in house by long term perm employees... >>it may feel unsound to those who are used to approving big change programs with detailed roadmap... If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy.

bonaldi 9y ago
>If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy. In large orgs, roadmaps come to be depended upon by stakeholders and other internal dependencies, who immediately base their roadmaps and thinking around yours. That means the cost of changing something on yours quickly mounts — it's no longer a matter of hoping your boss is flexible enough, almost your entire org has to be able to cope with a massive re-roadmapping exercise as the changes cascade through dependencies. Sure, you said 'high enough level of certainty'. And that's fine for building bridges. Less so software. Not least because it needlessly constrains innovation. If a team comes up with a better idea part-way through building something that's on a published roadmap, what does it do? Change the roadmap and cause all the upheaval above? Try and hit the original date even by starting over on the new idea? Or just plough on building what it now knows is a less-than-best idea? I've seen teams do each of these things, and cause needless misery, all because of unnecessary roadmapping. It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions.
- timv 9y ago
  > It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions. Yet, the extreme alternative of being entirely unable/unwilling to answer the question: "I need this, when are you able provide it?" also has huge repercusions. If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. If the internal "Database as a service" product team doesn't offer any sort of Geo capability, and I need it then I have to solve that problem. If that team cannot provide a roadmap, then I have to build a work around within my product team. This costs money, and that affects the P&L of the organisation. The organisation's goals are best met by having this capability built in the right place, with respect to upfront cost, ongoing cost and time to market. You need _some_ form of roadmap to make this stuff work. The argument is about size (volume and duration) and flexibility. But those aren't absolutes, and we can argue forever about "how big is too big?" (but let's not). And so we end up with articles that talk in vagaries like "big change programs with detailed roadmaps" which doesn't mean much.
  - bonaldi 9y ago
    > If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. Yes, you need co-ordination. No, you don’t need a roadmap. If you’re doing innovative new things, a roadmap is almost the worst possible way to try and co-operate on them. Let’s say you really do need your geo feature now. There are two happy answers from the DB PM: “we’re working on it now, estimate is x” or “it’s top of our list, we estimate starting on it after x”. Neither of these need a roadmap. The unhappy answer is something like “we’re not working on it, it’s fifth on our priority list”. You also don’t need a roadmap for this. In fact, this is a more honest and useful answer than the roadmap one — which would be something like “it’s behind four other things so slated for Q3”. The roadmap is a crutch to avoid the hard conversations about priority that are the core of good co-operation. Why? Because the roadmap suggests that while geo isn’t priority 1 now, somehow by the time Q3 rolls around it will be, and so you can start planning against that. That is going to leave you unhappy in Q3, almost for certain. Because the truth of the matter is implied in the priority list answer: “this is fifth to us. So we will work on it when we finish what we’re on now and if we get through the four things in front of it and if nothing else comes up as a higher priority in the meantime.” If you need geo, either way you now need to make a case for higher priority, to escalate, or figure out some other way to do what you want because clearly what you need isn’t an overall business priority. The roadmap also makes all those conversations harder because they become about dates and the PM can say “of course it matters to us we just can’t start it until Q3, do you really want to resequence all these other things? What about the impact on all the other dependencies? Seems bad”. Obviously this just leads to worse and worse conversations, until management steps in and says the real problem is a lack of transparency. What is really needed, they’ll say, are better roadmaps, ones that expose dependencies properly, ones that let the consequences be seen, ones with a much higher granularity. And a PMO to help us run it all. Before long, you’re no longer co-operating, you’re fighting over Gantt charts. This is the state of affairs the article is intending by “big change programs with detailed roadmaps”. And it can all be avoided by not pretending that work stretches out in front of us on a calendar. We don’t work on geo because Q3 has arrived and “we promised on the roadmap so I suppose we’d better”. We work on geo because of all the items on the shifting sands of priority, geo is the top one now and that priority is broadly agreed across the business. All you need are three ordered lists: “stuff in flight”, stuff that’s up next” and “stuff we’re looking at but haven’t committed to at all”. All the benefits of roadmap transparency and priority still surface, with none of the bad consequences of trying to express those things via a calendar.
timv 9y ago
>> for greater responsiveness and a higher benefits realization ratio, “product-mode” is a more effective way of working than projects. > This is a sweeping statement. It also can quickly degrade to being horribly untrue. A product team justifies its headcount and activity decisions in a silo. The product owner justifies a budget that translates roughly into team size and then sets to work on whatever satifies the objectives they've been given. But a recurring truth of large organisations is that silos evolve to justify their own existence and size. You keep having $N people costing $X working on product $T because the product owner justified it to someone, not because it delivers the high benefits realization across the organisation. The article's "New Silos" section just sweeps this to the side with "but it's better than the old silos". And it can be, but isn't definitively so. Any autonomous unit runs these risks, and unless the unit has its own P&L (with a real source of income, not just money taken from other people) preventing it from becoming bloated and serving its own desires (over the objectives of the organisation) takes hard work and requires proper oversight.
- theptip 9y ago
  Wouldn't it be easier to measure the P&L of a product (i.e. the output of a product-mode team), vs. the contribution of a single project to the company? I agree that the product/project dichotomy doesn't solve the silo problem entirely, but it seems to make it easier to tackle if the organization is inclined to do so. I think you're right that in the case of some organizations, the momentum of a product team could cause it to be harder to scale down than a project team (since it's expected that all project teams will wind down after a fixed time), but I don't think it's a clear win either way.
maaaats 9y ago
> People in IT should really stop to pretend that they are the only smart people that know how to run a business. But one problem I have seen as a consultant is companies don't realize they are software companies now. For instance, they are no longer a bank having a small IT department, IT is now their core business and should be treated as such.
- sidlls 9y ago
  No, IT is not their core business. Banking is. IT is a means to that end.
  - PeterStuer 9y ago
    Not to be nit-picky, but the 'means' to provide the result are in the core-business of the enterprise inseparable from 'the business'. Being in the 'conceptual' banking business without the means to do banking isn't going to fly. Same as casting a farm as a 'food produce provider' and telling them that farming is not what their core business is about. Semantically correct, but not useful for most purposes.
    - ckastner 9y ago
      Grandparent said IT is a means. There are other means to provide the core business of banking. There are banks who outsource / spin-off not only their IT, but even transaction processing and settlement. > Same as casting a farm as a 'food produce provider' and telling them that farming is not what their core business is about The correct analogy would be the other way round: a 'food produce provider' whose core business it is to distribute food produce. Here, too, the farm is a means to the end, but it's not the only means.
- myaso 9y ago
  Depends on the company, maybe some methods seem primitive by our standards but they can be extremely effective nonetheless. I strongly suspect a lot of it unnecessary, I've seen a VC funded startup tackle the same problem that someone solved with a mailing list. Software expertise seems to be the most expensive generic skill set that you can hire for anywhere today -- even if you hire the people they still might be crippled by having to work with legacy infrastructure; I've seen a live SCO Unix server not too long ago.

by cateye 9y ago

bonaldi 9y ago

>If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy. In large orgs, roadmaps come to be depended upon by stakeholders and other internal dependencies, who immediately base their roadmaps and thinking around yours. That means the cost of changing something on yours quickly mounts — it's no longer a matter of hoping your boss is flexible enough, almost your entire org has to be able to cope with a massive re-roadmapping exercise as the changes cascade through dependencies. Sure, you said 'high enough level of certainty'. And that's fine for building bridges. Less so software. Not least because it needlessly constrains innovation. If a team comes up with a better idea part-way through building something that's on a published roadmap, what does it do? Change the roadmap and cause all the upheaval above? Try and hit the original date even by starting over on the new idea? Or just plough on building what it now knows is a less-than-best idea? I've seen teams do each of these things, and cause needless misery, all because of unnecessary roadmapping. It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions.

timv 9y ago
> It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions. Yet, the extreme alternative of being entirely unable/unwilling to answer the question: "I need this, when are you able provide it?" also has huge repercusions. If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. If the internal "Database as a service" product team doesn't offer any sort of Geo capability, and I need it then I have to solve that problem. If that team cannot provide a roadmap, then I have to build a work around within my product team. This costs money, and that affects the P&L of the organisation. The organisation's goals are best met by having this capability built in the right place, with respect to upfront cost, ongoing cost and time to market. You need _some_ form of roadmap to make this stuff work. The argument is about size (volume and duration) and flexibility. But those aren't absolutes, and we can argue forever about "how big is too big?" (but let's not). And so we end up with articles that talk in vagaries like "big change programs with detailed roadmaps" which doesn't mean much.
- bonaldi 9y ago
  > If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap. Yes, you need co-ordination. No, you don’t need a roadmap. If you’re doing innovative new things, a roadmap is almost the worst possible way to try and co-operate on them. Let’s say you really do need your geo feature now. There are two happy answers from the DB PM: “we’re working on it now, estimate is x” or “it’s top of our list, we estimate starting on it after x”. Neither of these need a roadmap. The unhappy answer is something like “we’re not working on it, it’s fifth on our priority list”. You also don’t need a roadmap for this. In fact, this is a more honest and useful answer than the roadmap one — which would be something like “it’s behind four other things so slated for Q3”. The roadmap is a crutch to avoid the hard conversations about priority that are the core of good co-operation. Why? Because the roadmap suggests that while geo isn’t priority 1 now, somehow by the time Q3 rolls around it will be, and so you can start planning against that. That is going to leave you unhappy in Q3, almost for certain. Because the truth of the matter is implied in the priority list answer: “this is fifth to us. So we will work on it when we finish what we’re on now and if we get through the four things in front of it and if nothing else comes up as a higher priority in the meantime.” If you need geo, either way you now need to make a case for higher priority, to escalate, or figure out some other way to do what you want because clearly what you need isn’t an overall business priority. The roadmap also makes all those conversations harder because they become about dates and the PM can say “of course it matters to us we just can’t start it until Q3, do you really want to resequence all these other things? What about the impact on all the other dependencies? Seems bad”. Obviously this just leads to worse and worse conversations, until management steps in and says the real problem is a lack of transparency. What is really needed, they’ll say, are better roadmaps, ones that expose dependencies properly, ones that let the consequences be seen, ones with a much higher granularity. And a PMO to help us run it all. Before long, you’re no longer co-operating, you’re fighting over Gantt charts. This is the state of affairs the article is intending by “big change programs with detailed roadmaps”. And it can all be avoided by not pretending that work stretches out in front of us on a calendar. We don’t work on geo because Q3 has arrived and “we promised on the roadmap so I suppose we’d better”. We work on geo because of all the items on the shifting sands of priority, geo is the top one now and that priority is broadly agreed across the business. All you need are three ordered lists: “stuff in flight”, stuff that’s up next” and “stuff we’re looking at but haven’t committed to at all”. All the benefits of roadmap transparency and priority still surface, with none of the bad consequences of trying to express those things via a calendar.

timv 9y ago

>> for greater responsiveness and a higher benefits realization ratio, “product-mode” is a more effective way of working than projects. > This is a sweeping statement. It also can quickly degrade to being horribly untrue. A product team justifies its headcount and activity decisions in a silo. The product owner justifies a budget that translates roughly into team size and then sets to work on whatever satifies the objectives they've been given. But a recurring truth of large organisations is that silos evolve to justify their own existence and size. You keep having $N people costing $X working on product $T because the product owner justified it to someone, not because it delivers the high benefits realization across the organisation. The article's "New Silos" section just sweeps this to the side with "but it's better than the old silos". And it can be, but isn't definitively so. Any autonomous unit runs these risks, and unless the unit has its own P&L (with a real source of income, not just money taken from other people) preventing it from becoming bloated and serving its own desires (over the objectives of the organisation) takes hard work and requires proper oversight.

theptip 9y ago
Wouldn't it be easier to measure the P&L of a product (i.e. the output of a product-mode team), vs. the contribution of a single project to the company? I agree that the product/project dichotomy doesn't solve the silo problem entirely, but it seems to make it easier to tackle if the organization is inclined to do so. I think you're right that in the case of some organizations, the momentum of a product team could cause it to be harder to scale down than a project team (since it's expected that all project teams will wind down after a fixed time), but I don't think it's a clear win either way.

maaaats 9y ago

> People in IT should really stop to pretend that they are the only smart people that know how to run a business. But one problem I have seen as a consultant is companies don't realize they are software companies now. For instance, they are no longer a bank having a small IT department, IT is now their core business and should be treated as such.

sidlls 9y ago
No, IT is not their core business. Banking is. IT is a means to that end.
- PeterStuer 9y ago
  Not to be nit-picky, but the 'means' to provide the result are in the core-business of the enterprise inseparable from 'the business'. Being in the 'conceptual' banking business without the means to do banking isn't going to fly. Same as casting a farm as a 'food produce provider' and telling them that farming is not what their core business is about. Semantically correct, but not useful for most purposes.
  - ckastner 9y ago
    Grandparent said IT is a means. There are other means to provide the core business of banking. There are banks who outsource / spin-off not only their IT, but even transaction processing and settlement. > Same as casting a farm as a 'food produce provider' and telling them that farming is not what their core business is about The correct analogy would be the other way round: a 'food produce provider' whose core business it is to distribute food produce. Here, too, the farm is a means to the end, but it's not the only means.
myaso 9y ago
Depends on the company, maybe some methods seem primitive by our standards but they can be extremely effective nonetheless. I strongly suspect a lot of it unnecessary, I've seen a VC funded startup tackle the same problem that someone solved with a mailing list. Software expertise seems to be the most expensive generic skill set that you can hire for anywhere today -- even if you hire the people they still might be crippled by having to work with legacy infrastructure; I've seen a live SCO Unix server not too long ago.