Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Lean approach to IT development

•
•
Mark Krebs
Mark Krebs

The document discusses a 7-step approach to aligning business processes with application development. The steps include: 1) Committing IT resources to participate in process improvement projects. 2) Educating IT on current processes before detailed process mapping sessions. 3) Conducting value stream mapping sessions with IT to extract requirements and improve understanding. 4) Involving IT in root cause analysis. 5) Creating an ideal "to-be" process without constraints. 6) Using agile development methods to quickly build prototypes. 7) Continuing the cycle of process and technology improvements. The approach aims to close knowledge gaps and reduce communication issues between business and IT.

1 of 5
Download to read offline
............................................................................................................ 26 COST MANAGEMENT JANUARY/FEBRUARY 2016 W hen faced with deep- rooted process prob- lems, we tend to offer up similar solutions: “All we need is a bet- ter computer program.” “We just need more IT people to process our changes.” “At a previous employer, we used this application, and things were much smoother!” IT is often an easy scapegoat, just like the need for addi- tional staff, money, and time. While automation does help with quality, cycle time, and throughput, processes must be understood and streamlined before pursuing software changes. Too often technology is the comfortable blanket thrown over bad processes in hopes that all will be better once the storm passes. Usually the blanket is not enough, and we’re left with automated bad processes and a constant wonder- ment of how it got this way. There is a better technique that will both improve the process and speed up IT development time. The seven-step approach begins with a well-defined pro- ject charter, continues with detailed process sessions, and ends with con- current process improvement and system implementation. It aligns business and IT resources and reduces the communi- cation handoffs and misunderstandings that are inevitable in process and IT sys- tem transformation. Requirements are collected during the as-is (current state) and to-be (future state) value stream mapping (VSM) sessions, and IT repre- sentatives are deeply engaged from begin- ning to end. Let’s look at each of these steps in detail. Step one: Commitment to the charter IT management, business analysts, and programmers need to be included as resources in the process improvement project charter. Detailing their involve- ment and getting up-front commitment to participate in events such as the VSM sessions is essential. Most IT organi- zations will be reluctant and resistant and may look at you with dazed won- derment as to why technical resources need to be involved in “process stuff.” Typical responses have included: “Just tell us the requirements, and we’ll build it for you”; “I don’t need my valuable resources tied up in meetings all day! I need them pounding code!”; and “You THELEAN APPROACHTO APPLICATION DEVELOPMENTMA R K S. KR EB S MARK S. KREBS is an ASQ Certified Lean Black Belt practitioner who has been transforming business processes and implementing software solutions for over 25 years. Mark can be reached at Mark.Krebs@outlook.com. IT resources can build a closer connection to the process owners and deliver impactful technological changes that will transform your company.
............................................................................................................................................................................. don’t want Joe in that meeting; he’s not good with people.” The most critical aspect at this step is for both IT and business manage- ment to fully understand and commit to the participation of IT resources in VSM meetings, as well as the benefits of doing so. Involvement in VSM closes the knowledge gap that often exists between the business and IT groups. IT gains an in-depth understanding of the business processes and strategic direction and can fit the available tech- nological tools to the true business needs. The relationship and under- standing developed by both sides reduces repetitive explanations and jus- tifications for why a feature, field, inter- face, or screen is needed. Getting the sponsors to see the benefits through a 30- to 60-minute interactive simulated VSM meeting is impactful. Lastly, make it clear in the charter (and in the meetings in which the char ter is dis- cussed) that the VSM meetings cannot be an optional endeavor. IT resources need to be considered as important as the small or medium-sized enterprise that executes the process on a daily basis. Discuss and agree upon actions that should occur if participation and attendance begin to decline. Step two: Before the VSM meetings For large projects, high- and mid-level process maps can be created outside of large cross-functional meetings involv- ing IT. The important part of this step is for IT resources to understand the high- to mid-level suppliers, inputs, process, outputs, and customers so that there is context going into the VSM meet- ings. An understanding of current sys- tems, measures, bottlenecks, and key business plan points is valuable but not crucial at this stage. These items will be discussed and detailed in the meetings. The goal is to incrementally build up business knowledge, and hopefully inter- est, within the IT staff. Accept that mul- tiple communication attempts and tech- niques will be necessar y with IT resources. For organizations in which IT resources have previous business expertise, solicit their help in reviewing and critiquing these artifacts. These resources can be valuable throughout the project in providing cross-functional viewpoints. Step three: The VSM meetings We’ll use a generic form intake process to illustrate how the sessions can extract system requirements and streamline com- munication cycles between the business and IT. In the conference room, we have rep- resentatives of the suppliers to the process, the process owners, customers of the process, and IT. Armed with a blank wall and large colored sticky notes to represent waste or value-added activ- ities, we begin. Beginning with the receipt of the form, we follow it one step at a time through the process. The process experts explain the first steps, and we create the first steps of the process (see Exhibit 1). Let’s stop here and ask a few ques- tions. If not prompted by IT resources, the facilitator should delve into these steps a bit more by asking: • Why email? Could the requester enter his or her own information? If email is required, can we use a stan- dard template? • Why is a cheat sheet being used to look up customers? (Is the customer database not reliable or not updated frequently, or is searching the data- base cumbersome?) • How often do requests come in without the required information? • What data elements are entered? What is each used for in the process? • If entering a new customer, how does the system alert you to dupli- cates? Thirty minutes later, as facilitator, you start panicking. We’re only on step three, and it’s 10 a.m.! Don’t panic — the first three to five steps are always the most difficult. The conversation con- 27IT RESOURCES JANUARY/FEBRUARY 2016 COST MANAGEMENT THE GOAL IS TO INCREMENTALLY BUILD UP BUSINESS KNOWLEDGE, AND HOPEFULLY INTEREST, WITHIN THE IT STAFF.
tinues, and the minds of IT resources are spinning and rapidly vocalizing solutions: “We could have a portal! No, wait, we can write that in HTML 5 and then use a stored proc in C# and then have it call a method too.” “Time-out,” I say, “Great ideas, Joe. Let’s put them on the ‘great ideas’ flip chart.” It’s important to let people think about the solutions and capture ideas so that they feel heard, but the important part is to capture the base requirements needed.With that I ask,“So, business, what information is captured here, and what’s the information used for?” What we have started to create is ow nership by IT and a par tnership between IT and the business. As the session continues, the business should learn that IT is not the department of “no,” and IT should learn that the busi- ness is not a bunch of whiners who just keep requesting “dumb” stuff. The linch- pin in this session is that we’re relay- ing core system requirements directly to the IT staff in context of the busi- ness process. As the business explains the necessary data and the reasons for the data, the IT staff further understands what is crit- ical and why. The business will also clar- ify, and sometimes eliminate, the need for a system requirement that would have previously been submitted to IT. For example, Suzie from the business says in the session, “For step one, we need a report to show us all the requests that were submitted between 8 a.m. and 10:30 a.m.” “Okay,” I respond,“What question are you trying to answer?” “Well, we had a problem a few years ago when the system went down and lost all the data. We save the data to a shared drive and then print it out so that we have a backup if the system goes down.” 28 COST MANAGEMENT JANUARY/FEBRUARY 2016 IT RESOURCES EXHIBIT 1 Detailed Process Flow .................................................................................
The group is then informed by the IT staff that this problem was resolved years ago through redundant servers and a whole bunch of technical terms that are quite impressive. This rapid exchange of information separating myth from truth is a common benefit of having the busi- ness and IT in one room. It allows for a process-driven discussion of the request in real time instead of IT focusing on fulfilling the initial report request from a request list. Step four: Root cause analysis (RCA) Yes, involve IT in the RCA (the five whys, fishbone diagrams, etc.). Often they will serve as a wonderful analyti- cal outsider with no attachment to the current process and its problems. In return, the IT staff should build a bit of empathy for the business and, if all goes well, a stronger relationship with the process owners. Step five: The to-be Forgetting all of the current constraints, skill limitations of the staff, and orga- nizational structure, we venture into the to-be w ith a blank wall and the trusty colorful sticky notes. The pur- pose is to document the ideal process so that it can be used during the design and implementation phases. Although getting people out of the current-state system limitations is difficult, it can be done. This is the time for the IT resources to shine and panic — shine because they know what the technology can do, and panic because the process experts will verbalize a plethora of ideas and ask them if they’re possible. A good response for our IT staff should be something like, “Let’s decide what you need, and then we’ll figure out the best way to get you there.” Coming out of the to-be, we should have enough infor- mation for the mid-level IT require- ments and over 50 percent of the detailed requirements (fields, validations, stor- age requirements, etc.). Due to IT’s involvement and commitment, we have technical resources that are educated on the business process and have started breaking down the communication walls that typically exist between the business and technical teams. Step six: Now is the time to use agile methods Coming out of our rapid improvement event, everyone is ready to get going! Then, the killjoy of projects enters the picture: the formal business requirement document. If you want to kill momen- tum, spend weeks to months on a doc- ument that few in the business will read and want to understand. If possible, use the agile techniques that work for your organization and get some working pro- totypes going. IT should start on one piece of the change that can be quickly visible to the business and work on the behind-the-scenes IT work in parallel. Don’t get me wrong, server provisioning, entity rela- tionship diagrams, and single sign- on are fascinating topics — but not to the business. The business and IT should have weekly show-and-tells to shorten development time and avoid unnecessary code and rework. Each request can be tied back to the to-be process map and questioned if the request is trying to re-create the cur- rent state. For example, if it’s agreed that all work should go into a queue from which workers select the next item, an IT requirement that assigns items to an individual needs to be rejected. Step seven: Continue the cycle What we have created now is a synergy between the business and IT and a rela- tionship that allows a free flow of ideas as well as a deep understanding of the current process and the direction of the future process. User acceptance testing is much easier, and the likelihood of sys- tem acceptance is increased due to the developed relationship. Don’t forget that the business also needs to hold up its end of the bargain to change while IT is layering technology over the to-be process. The fundamental process and organizational changes agreed upon in the VSM sessions must be planned and 29IT RESOURCES JANUARY/FEBRUARY 2016 COST MANAGEMENT WHAT WE HAVE CREATED NOW IS A SYNERGY BETWEEN THE BUSINESS AND IT AND A RELATIONSHIP THAT ALLOWS A FREE FLOW OF IDEAS AS WELL AS A DEEP UNDERSTANDING OF THE CURRENT PROCESS AND THE DIRECTION OF THE FUTURE PROCESS. .............................................................................................................................................................................
30 COST MANAGEMENT JANUARY/FEBRUARY 2016 IT RESOURCES implemented concurrently with the sys- tem development activities. This bal- ance of keeping both the business and IT synchronized and focused on the to-be process is challenging and requires vig- ilant nurturing; however, it also pro- duces robust processes supported by solid applications that will revolution- ize your company if successful. So if you find that your IT projects are mired in unfulfilled expectations, countless delays, and internal squab- bling, try this approach. Find a way to have IT resources deeply involved with the business and process transforma- tion and then have them help you layer technology on the new and improved business processes. n REPRINTS Theprofessionalwaytosharetoday’sbest thinkingoncrucialtopicswithyourcolleaguesandclients. Now it’s easy for you to obtain affordable, professionally bound copies of especially pertinent articles from this journal. With our reprints, you can: • Communicate new ideas and techniques that have been developed by leading industry experts • Keep up with new developments – and how they affect you and your clients • Enhance in-house training programs • Promote your products or services by offering copies to clients • And much more For additional information about our reprints or to place an order, call: 1-973-942-2243 • REPRINTS Please remember that articles appearing in this journal may not be reproduced without permission of the publisher. ...................................................................................................

More Related Content

Lean approach to IT development

  • 1. ............................................................................................................ 26 COST MANAGEMENT JANUARY/FEBRUARY 2016 W hen faced with deep- rooted process prob- lems, we tend to offer up similar solutions: “All we need is a bet- ter computer program.” “We just need more IT people to process our changes.” “At a previous employer, we used this application, and things were much smoother!” IT is often an easy scapegoat, just like the need for addi- tional staff, money, and time. While automation does help with quality, cycle time, and throughput, processes must be understood and streamlined before pursuing software changes. Too often technology is the comfortable blanket thrown over bad processes in hopes that all will be better once the storm passes. Usually the blanket is not enough, and we’re left with automated bad processes and a constant wonder- ment of how it got this way. There is a better technique that will both improve the process and speed up IT development time. The seven-step approach begins with a well-defined pro- ject charter, continues with detailed process sessions, and ends with con- current process improvement and system implementation. It aligns business and IT resources and reduces the communi- cation handoffs and misunderstandings that are inevitable in process and IT sys- tem transformation. Requirements are collected during the as-is (current state) and to-be (future state) value stream mapping (VSM) sessions, and IT repre- sentatives are deeply engaged from begin- ning to end. Let’s look at each of these steps in detail. Step one: Commitment to the charter IT management, business analysts, and programmers need to be included as resources in the process improvement project charter. Detailing their involve- ment and getting up-front commitment to participate in events such as the VSM sessions is essential. Most IT organi- zations will be reluctant and resistant and may look at you with dazed won- derment as to why technical resources need to be involved in “process stuff.” Typical responses have included: “Just tell us the requirements, and we’ll build it for you”; “I don’t need my valuable resources tied up in meetings all day! I need them pounding code!”; and “You THELEAN APPROACHTO APPLICATION DEVELOPMENTMA R K S. KR EB S MARK S. KREBS is an ASQ Certified Lean Black Belt practitioner who has been transforming business processes and implementing software solutions for over 25 years. Mark can be reached at Mark.Krebs@outlook.com. IT resources can build a closer connection to the process owners and deliver impactful technological changes that will transform your company.
  • 2. ............................................................................................................................................................................. don’t want Joe in that meeting; he’s not good with people.” The most critical aspect at this step is for both IT and business manage- ment to fully understand and commit to the participation of IT resources in VSM meetings, as well as the benefits of doing so. Involvement in VSM closes the knowledge gap that often exists between the business and IT groups. IT gains an in-depth understanding of the business processes and strategic direction and can fit the available tech- nological tools to the true business needs. The relationship and under- standing developed by both sides reduces repetitive explanations and jus- tifications for why a feature, field, inter- face, or screen is needed. Getting the sponsors to see the benefits through a 30- to 60-minute interactive simulated VSM meeting is impactful. Lastly, make it clear in the charter (and in the meetings in which the char ter is dis- cussed) that the VSM meetings cannot be an optional endeavor. IT resources need to be considered as important as the small or medium-sized enterprise that executes the process on a daily basis. Discuss and agree upon actions that should occur if participation and attendance begin to decline. Step two: Before the VSM meetings For large projects, high- and mid-level process maps can be created outside of large cross-functional meetings involv- ing IT. The important part of this step is for IT resources to understand the high- to mid-level suppliers, inputs, process, outputs, and customers so that there is context going into the VSM meet- ings. An understanding of current sys- tems, measures, bottlenecks, and key business plan points is valuable but not crucial at this stage. These items will be discussed and detailed in the meetings. The goal is to incrementally build up business knowledge, and hopefully inter- est, within the IT staff. Accept that mul- tiple communication attempts and tech- niques will be necessar y with IT resources. For organizations in which IT resources have previous business expertise, solicit their help in reviewing and critiquing these artifacts. These resources can be valuable throughout the project in providing cross-functional viewpoints. Step three: The VSM meetings We’ll use a generic form intake process to illustrate how the sessions can extract system requirements and streamline com- munication cycles between the business and IT. In the conference room, we have rep- resentatives of the suppliers to the process, the process owners, customers of the process, and IT. Armed with a blank wall and large colored sticky notes to represent waste or value-added activ- ities, we begin. Beginning with the receipt of the form, we follow it one step at a time through the process. The process experts explain the first steps, and we create the first steps of the process (see Exhibit 1). Let’s stop here and ask a few ques- tions. If not prompted by IT resources, the facilitator should delve into these steps a bit more by asking: • Why email? Could the requester enter his or her own information? If email is required, can we use a stan- dard template? • Why is a cheat sheet being used to look up customers? (Is the customer database not reliable or not updated frequently, or is searching the data- base cumbersome?) • How often do requests come in without the required information? • What data elements are entered? What is each used for in the process? • If entering a new customer, how does the system alert you to dupli- cates? Thirty minutes later, as facilitator, you start panicking. We’re only on step three, and it’s 10 a.m.! Don’t panic — the first three to five steps are always the most difficult. The conversation con- 27IT RESOURCES JANUARY/FEBRUARY 2016 COST MANAGEMENT THE GOAL IS TO INCREMENTALLY BUILD UP BUSINESS KNOWLEDGE, AND HOPEFULLY INTEREST, WITHIN THE IT STAFF.
  • 3. tinues, and the minds of IT resources are spinning and rapidly vocalizing solutions: “We could have a portal! No, wait, we can write that in HTML 5 and then use a stored proc in C# and then have it call a method too.” “Time-out,” I say, “Great ideas, Joe. Let’s put them on the ‘great ideas’ flip chart.” It’s important to let people think about the solutions and capture ideas so that they feel heard, but the important part is to capture the base requirements needed.With that I ask,“So, business, what information is captured here, and what’s the information used for?” What we have started to create is ow nership by IT and a par tnership between IT and the business. As the session continues, the business should learn that IT is not the department of “no,” and IT should learn that the busi- ness is not a bunch of whiners who just keep requesting “dumb” stuff. The linch- pin in this session is that we’re relay- ing core system requirements directly to the IT staff in context of the busi- ness process. As the business explains the necessary data and the reasons for the data, the IT staff further understands what is crit- ical and why. The business will also clar- ify, and sometimes eliminate, the need for a system requirement that would have previously been submitted to IT. For example, Suzie from the business says in the session, “For step one, we need a report to show us all the requests that were submitted between 8 a.m. and 10:30 a.m.” “Okay,” I respond,“What question are you trying to answer?” “Well, we had a problem a few years ago when the system went down and lost all the data. We save the data to a shared drive and then print it out so that we have a backup if the system goes down.” 28 COST MANAGEMENT JANUARY/FEBRUARY 2016 IT RESOURCES EXHIBIT 1 Detailed Process Flow .................................................................................
  • 4. The group is then informed by the IT staff that this problem was resolved years ago through redundant servers and a whole bunch of technical terms that are quite impressive. This rapid exchange of information separating myth from truth is a common benefit of having the busi- ness and IT in one room. It allows for a process-driven discussion of the request in real time instead of IT focusing on fulfilling the initial report request from a request list. Step four: Root cause analysis (RCA) Yes, involve IT in the RCA (the five whys, fishbone diagrams, etc.). Often they will serve as a wonderful analyti- cal outsider with no attachment to the current process and its problems. In return, the IT staff should build a bit of empathy for the business and, if all goes well, a stronger relationship with the process owners. Step five: The to-be Forgetting all of the current constraints, skill limitations of the staff, and orga- nizational structure, we venture into the to-be w ith a blank wall and the trusty colorful sticky notes. The pur- pose is to document the ideal process so that it can be used during the design and implementation phases. Although getting people out of the current-state system limitations is difficult, it can be done. This is the time for the IT resources to shine and panic — shine because they know what the technology can do, and panic because the process experts will verbalize a plethora of ideas and ask them if they’re possible. A good response for our IT staff should be something like, “Let’s decide what you need, and then we’ll figure out the best way to get you there.” Coming out of the to-be, we should have enough infor- mation for the mid-level IT require- ments and over 50 percent of the detailed requirements (fields, validations, stor- age requirements, etc.). Due to IT’s involvement and commitment, we have technical resources that are educated on the business process and have started breaking down the communication walls that typically exist between the business and technical teams. Step six: Now is the time to use agile methods Coming out of our rapid improvement event, everyone is ready to get going! Then, the killjoy of projects enters the picture: the formal business requirement document. If you want to kill momen- tum, spend weeks to months on a doc- ument that few in the business will read and want to understand. If possible, use the agile techniques that work for your organization and get some working pro- totypes going. IT should start on one piece of the change that can be quickly visible to the business and work on the behind-the-scenes IT work in parallel. Don’t get me wrong, server provisioning, entity rela- tionship diagrams, and single sign- on are fascinating topics — but not to the business. The business and IT should have weekly show-and-tells to shorten development time and avoid unnecessary code and rework. Each request can be tied back to the to-be process map and questioned if the request is trying to re-create the cur- rent state. For example, if it’s agreed that all work should go into a queue from which workers select the next item, an IT requirement that assigns items to an individual needs to be rejected. Step seven: Continue the cycle What we have created now is a synergy between the business and IT and a rela- tionship that allows a free flow of ideas as well as a deep understanding of the current process and the direction of the future process. User acceptance testing is much easier, and the likelihood of sys- tem acceptance is increased due to the developed relationship. Don’t forget that the business also needs to hold up its end of the bargain to change while IT is layering technology over the to-be process. The fundamental process and organizational changes agreed upon in the VSM sessions must be planned and 29IT RESOURCES JANUARY/FEBRUARY 2016 COST MANAGEMENT WHAT WE HAVE CREATED NOW IS A SYNERGY BETWEEN THE BUSINESS AND IT AND A RELATIONSHIP THAT ALLOWS A FREE FLOW OF IDEAS AS WELL AS A DEEP UNDERSTANDING OF THE CURRENT PROCESS AND THE DIRECTION OF THE FUTURE PROCESS. .............................................................................................................................................................................
  • 5. 30 COST MANAGEMENT JANUARY/FEBRUARY 2016 IT RESOURCES implemented concurrently with the sys- tem development activities. This bal- ance of keeping both the business and IT synchronized and focused on the to-be process is challenging and requires vig- ilant nurturing; however, it also pro- duces robust processes supported by solid applications that will revolution- ize your company if successful. So if you find that your IT projects are mired in unfulfilled expectations, countless delays, and internal squab- bling, try this approach. Find a way to have IT resources deeply involved with the business and process transforma- tion and then have them help you layer technology on the new and improved business processes. n REPRINTS Theprofessionalwaytosharetoday’sbest thinkingoncrucialtopicswithyourcolleaguesandclients. Now it’s easy for you to obtain affordable, professionally bound copies of especially pertinent articles from this journal. With our reprints, you can: • Communicate new ideas and techniques that have been developed by leading industry experts • Keep up with new developments – and how they affect you and your clients • Enhance in-house training programs • Promote your products or services by offering copies to clients • And much more For additional information about our reprints or to place an order, call: 1-973-942-2243 • REPRINTS Please remember that articles appearing in this journal may not be reproduced without permission of the publisher. ...................................................................................................