This past week I read a post on the Cutter Consortium blog by Bob Benson entitled, "A Shift in the Notion of Portfolio Management Opens Opportunity for IT". Bob begins the post with,
The problem is that the level of collaboration required for effective software development precludes the use of the Service-Consumer model. As I wrote in Embedded Collaboration in 2008,
First, it can create a local optimzation at the business unit level, i.e. the immediate software needs of that unit are being satisfied, but perhaps what is created could have been shared with the organization as a whole. To address this you would require some form of communication and collaboration between the software development groups of each business unit.
Second, once an application or business process crosses business unit boundaries, you're not in Kansas anymore - you can't simply "go native" across the whole organization. In that case, the discipline of product management become even more important, with the need for a more strategic view of the organization to be used to guide the team. That said, though, there is still no reason for the people who are building the applications to belong to an IT service organization - they should be part of a product team that includes close, frequent (ideally daily) participation from the business.
The third problem is that not all business units are created equal. It can be much more difficult for Human Resources to justify its own software development budget compared to a business unit that is directly creating revenue for the company (ironically, the first time I encountered Embedded Collaboration, it was in a Human Resources Systems group). To address this, you may need to have a product delivery group that spans multiple smaller business units. The key, though, is not to look at what a business unit either contributes to or takes away from the organization's bottom line, but rather at the impact of that unit on the business. Human Resources may be considered "overhead", but its impact on the business of any medium to large organization far outscales its size.
I do agree with Bob Benson that there is a blurring of the lines between the activities performed in IT groups now. However, I don't agree that the Service-Consumer model is appropriate for software development activities. I've met Bob, and have a lot of respect for his experience. However, I've seen that model when applied to software development create many more problems than it has solved. It has created artificial divisions that impeded true collaboration, and thus negatively impacted the delivery of software.
If you believe that the Service-Consumer model is appropriate, allow me to quote Dr. Phil,
For many years,Tom Bugnitz and I have been recommending that IT organizations think of themselves as a service business, with five fundamental service portfolios.He goes on to describe how he's now seeing the boundaries between these service portfolios become blurred, with which I agree. What I don't agree with, though, is the suggestion that IT organizations much act like a service business, at least not for the part of IT that build applications for use by the business.
1. The Application Portfolio (e.g., providing the applications and support to business units)
2. The Project Portfolio
3. The Infrastructure Services Portfolio (e.g., e-mail, network attach, remote access)
4. The User Services Portfolio (e.g., help desk, PC repair)
5. The Management Services Portfolio (e.g., providing procurement, planning support to business units)
The problem is that the level of collaboration required for effective software development precludes the use of the Service-Consumer model. As I wrote in Embedded Collaboration in 2008,
There is no functional separation of business and IT on a project - they are living and working together, breathing the same air, meeting at the same water coolers.The most obvious way to accomplish this is to have the software development people "go native" and physically sit with the business people for whom they are building software (I also wrote about this in Agile Circa 1988). Create product teams within each business unit whose sole reason for existence is to serve the software development needs for that unit. The business unit is responsible for establishing it's own software development budget, and for feeding the product team with a constantly groomed list of prioritized features that they require. There are some potential problems with that model, though.
First, it can create a local optimzation at the business unit level, i.e. the immediate software needs of that unit are being satisfied, but perhaps what is created could have been shared with the organization as a whole. To address this you would require some form of communication and collaboration between the software development groups of each business unit.
Second, once an application or business process crosses business unit boundaries, you're not in Kansas anymore - you can't simply "go native" across the whole organization. In that case, the discipline of product management become even more important, with the need for a more strategic view of the organization to be used to guide the team. That said, though, there is still no reason for the people who are building the applications to belong to an IT service organization - they should be part of a product team that includes close, frequent (ideally daily) participation from the business.
The third problem is that not all business units are created equal. It can be much more difficult for Human Resources to justify its own software development budget compared to a business unit that is directly creating revenue for the company (ironically, the first time I encountered Embedded Collaboration, it was in a Human Resources Systems group). To address this, you may need to have a product delivery group that spans multiple smaller business units. The key, though, is not to look at what a business unit either contributes to or takes away from the organization's bottom line, but rather at the impact of that unit on the business. Human Resources may be considered "overhead", but its impact on the business of any medium to large organization far outscales its size.
I do agree with Bob Benson that there is a blurring of the lines between the activities performed in IT groups now. However, I don't agree that the Service-Consumer model is appropriate for software development activities. I've met Bob, and have a lot of respect for his experience. However, I've seen that model when applied to software development create many more problems than it has solved. It has created artificial divisions that impeded true collaboration, and thus negatively impacted the delivery of software.
If you believe that the Service-Consumer model is appropriate, allow me to quote Dr. Phil,
How's that workin' for ya?
Comments