{"id":99,"date":"2010-11-14T20:51:02","date_gmt":"2010-11-14T19:51:02","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=99"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"lean-principles-for-multi-project-environments","status":"publish","type":"post","link":"https:\/\/leanmagazine.net\/lean\/lean-principles-for-multi-project-environments\/","title":{"rendered":"Lean principles for multi project environments"},"content":{"rendered":"

In a second conversation with\u00a0Mary Poppendieck, Anders Sixtensson had the opportunity to discuss Lean Principles in a multiproject environment, and especially how these can be applied to improve the business throughput. One source Mary came back to several times was Randy Mott, CIO of Dell and later Hewlett Packard, whose ideas have had an enormous impact on the industry on how to run IT-organizations.<\/strong><\/p>\n

\"\"<\/a>
\n<\/strong>Anders: I would like us to discuss how Lean can work in a multi project organization like a centralized IT organization.<\/strong><\/p>\n

Mary: We often see that IT departments are not able to think the same way as the businesses they support.
\nThis was true at 3M, and to some extent is also true at Toyota. IT departments that are embedded in relatively small business units are uniformly more responsive than separate organizations. So what I think is wrong is the very concept of IT Projects in the first place. I always look for the ultimate owner of the responsibility for IT success. A McKinsey study claims that only when business execs are held responsible for their investments in IT do they assure the success of those investments. In most other cases, IT results are mediocre, nomatter what the competence of the IT department, their systems, etc.<\/p>\n

So, how would you organize the IT resources? <\/strong><\/p>\n

When IT is closer to the money, itdrives the right behavior. I would align a set of people with a relatively small business unit and have them contribute to business projects. Okay, so some business units are large. Still, same approach. There is no such thing as an IT project, there are only business projects. I recommend the strategy of Inditex for your consideration. There, they do NOTHING absent a very clear pull from the business. They spend about 0.5% of sales on IT.<\/p>\n

In IT organization you always split your efforts between innovation and \u201ckeep-the-lights-on\u201d. What have you seen as \u201cbest-practice\u201d?<\/strong><\/p>\n

When Randy Mott moved from WalMart to become became the CIO of Dell in 2000, he found that approximately 70% of all IT effort was spent doing \u201clights-on\u201d work. He set a goal of reducing \u201clights-on\u201d work to 25% of IT spending in five years. Within three years, 30% of Dell\u2019s IT organization had shifted focus from keeping the lights on to innovation, almost tripling Dell\u2019s return on investment in IT.<\/p>\n

What is important from a Lean perspective to have in mind if you would manage a portfolio of projects?<\/strong><\/p>\n

The important thing to have in mind is your customer. First of all, you have a downstream customer, and ultimately the results of software development provide value to someone who pays or spends time with the final product that software is a part of. The thing to focus on is the timeline from when that final customer expresses a need or sends in an order until they get whatthey need and are using it. This timeline \u2013 from concept to cash \u2013 should be as short as possible with (ideally) no time or effort expended that is not focused on delivering customer value.<\/p>\n

How can you understand what your time line is today? <\/strong><\/p>\n

In our classes we have people draw a value stream map of this timeline: they lay out the main steps from concept to cash and put in average times for each step. Then they determine how much of that time was spent actually adding value. Often less that 10% of the time is spent adding value, and from the point of view of Lean, the rest of the time is waste. The places in the value stream map where things slow down point out the best opportunities to improve the process. Large queues are often found between departments, indicating a lack of communication. Loop-backs are also indicators of waste. For example, we often see that over 50% of requirements have to be changed after they are written. This means that they were written to\u00a0 soon. Very frequently we see a huge test-and-fix step, which means that testing occurred too late.<\/p>\n

You mention in your latest book \u201cplan thoughtfully and commit sparingly\u201d and I know that my clients on the business side ordering IT services would have a hard time to accept this. The lack of trust seem to be the underlying reason for much of the behavior.<\/strong><\/p>\n

You are certainly right; a lack of trust is driving this behavior. I think the underlying problem is thinking of IT as a different entity than the business. (Am I sounding like a broken record?) It is contractual thinking generated by a \u201cwethey\u201d divide that drives businesses to seek premature commitment from IT. Think of it this way \u2013 the commitment of IT should match the commitment of the business. For example, the overall revenue of a business unit is usually seen as a commitment to the markets, because if the business does not meet its public projections, the stock market will kill it. Thus these projections are truly considered a commitment. How they will be achieved, however, remains to be determined as the year (or quarter) unfolds. Why treat IT any differently? No problem with a high level commitment, but HOW that commitment is achieved remains to be determined as the business needs unfold.<\/p>\n

Finally, Lean is much about removing waste. What is the common waste in a multi project environment?<\/strong><\/p>\n

I think that the biggest waste in a multi project environment is thinking that it is a good thing to do a lot of projects at the same time. Lean thinking teaches exactly the opposite: Do the most important thing first, do it quickly and well, get it done, and then go on to the next most important thing. The payoff from each project will come far earlier, and the overall resource need will be significantly lower. Let\u2019s say you have three projects to do, and each will take a month. Assume, for the sake of argument, that you can\u2019t decide which is the most important, so you work on all three at once. What happens? Instead of getting one project done at the end of month 1, the second done at the end of month 2, and the third done at the end of month 3, NOTHING gets done until month 5! Why is this? Task switching takes time, delays introduce the need for change, and lack of focus introduces quality problems. Stop thinking \u201clarge project\u201d and start thinking \u201cseries of small projects\u201d. We already talked about Randy Mott, who as CIO of Dell limited development cycle time to six months. He also reduced the number of strategic initiatives at Dell from 250 to 12. In 2005, Mott moved from Dell to become CIO of Hewlett Packard. The first thing he did was to reduce the number of projects from 1500 to a couple hundred. Mott says: \u201cIf you at least limit the number of things you go after, you can actually get them done faster and get more things done in the same amount of time.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"

In a second conversation with\u00a0Mary Poppendieck, Anders Sixtensson had the opportunity to discuss Lean Principles in a multiproject environment, and especially how these can be applied to improve the business throughput. One source Mary came back to several times was Randy Mott, CIO of Dell and later Hewlett Packard, whose […]<\/p>\n","protected":false},"author":32,"featured_media":185,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,5,83],"tags":[6,29,37,16],"_links":{"self":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/99"}],"collection":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=99"}],"version-history":[{"count":21,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/99\/revisions"}],"predecessor-version":[{"id":1053,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/99\/revisions\/1053"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/185"}],"wp:attachment":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=99"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=99"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=99"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}