╨╧рб▒с>■  QS■   P                                                                                                                                                                                                                                                                                                                                                                                                                                                ье┴{` Ё┐j=bjbjюFюF *PМ,М,!5H      д,,,,,,,@ddd8Ь░4@ъЁЁЁЁЁЁЁЁЕЗЗЗЗЗЗ$ЁhX╩л,ЁЁЁЁЁл,,ЁЁ└RRRЁv,Ё,ЁЕRЁЕRR╠,,Ёф `дОШ▐M─dfФ═!d╓0ч"·"4", ЁЁRЁЁЁЁЁлл·XЁЁЁЁЁЁЁ@@@$ d@@@d@@@,,,,,,     Checklist: Software Integration Phase Planning & Execution What: A checklist that gives the project manager or software integration team leader a way to analyze, plan, communicate and execute the Integration Phase of a large or complex software project. The checklist gives reminders of needed activities and suggested behaviors that are not necessarily documented in the project life cycle. The checklist may be useful for project managers in IT or other areas that have to integrate off-the-shelf components. Also, many projects do not have an explicit "Integration Phase", but the checklist gives some suggestions on integrating the various components, sub-systems, etc. of a project and can be tailored to a complex, non-software project. Background: Project Management "Integration" Description: What is the common use of the term "Integration" in project management? "Integration Management" in the PMBOK (PMI's Project Management Body of Knowledge) is commonly thought of as the process of applying a project organizational structure onto a project team, whether it is in common or not, with the organizational structure of the contracting entity (i.e. corporation). The other common application of the term is the process the project manager goes through in planning and organizing a team with diverse skills and deliverables, and rolling them all up into the product or set of deliverables of the project. Software Integration Phase Description: What do we mean by Integration Phase? In large projects involving a medium to large software development effort, multiple modules, sub-modules, components, pieces, functions, methods, etc. (you pick your favorite term for "parts") are required to all come together into a cohesive product (i.e. application) or multiple products (i.e. client and server software). A common technique for this is to add a phase that overlaps the end of Development and the beginning of Test (this is a simple description). This is the "integration phase" of a software project. It is also a common phase in many projects other than software, but experience has taught us that particularly for large, complex projects, explicitly adding it as a unique phase and having an Integration Plan and Integration WBS greatly increases the chances for success. There are 2 major techniques or philosophical approaches to the Software Integration Phase. These are the "non-incremental integration" method and the "incremental integration" method. The historical technique is called the "non-incremental integration" method. It is also known as the "big bang" approach. In implementing this method, all modules and components are combined immediately before testing and the entire program or programs are tested as a whole. Chaos is usually the rule of thumb, with the associated increase in gray hair for all involved. There is an associated behavior common to this method which is colloquially referred to as "over the wall". This entails developers submitting their modules, functions, etc. and then throwing the results "over the wall" to let the testers, the poor unfortunates working in the next phase of the project, figure out the ensuing mess. The "incremental integration" is a planned, process-oriented method for pulling all the software parts together into a cohesive whole with predictable results and measurable milestones. The primary philosophy of incremental integration is to construct a series of smaller, component-level integrations and test in small increments. As the population of these integrated components grows, they are combined into one-size-larger components and tested again. This activity is performed repeatedly until all the components are combined into the expected program or set of programs. Failures at the smaller integration steps allow easier error analysis since there is a limit to the amount of components that could be affecting the integrated component. Two well-known and commonly practiced methods and processes for implementing the incremental integration method are 1) Top-Down Integration method and 2) the Bottom-Up Integration method. These sound simple, but these are rather complex approaches and outside the scope of this paper. A good Software Engineering text or reference will have a description. What if I don't project manage Software projects? All projects have an implicit or explicit integration phase. It's the part of the project where components get put together and are expected to work, make sense, interact, etc. The checklist is worth a review for any project managers that deal with diverse, complex or divergent components that are expected to interact with each other to form the final product or deliverable Why: This checklist highlights considerations that the project manager or integration team leader can use to minimize risks and delays inherent to the Integration Phase. Following a plan and executing against that plan relieves the team of suffering through the УBig BangФ approach to integration. The checklist helps with focusing the team and evangelizing to management the need for early activities and the need for participation by team members that may not have been involved in the past. It helps also by assertively pushing for a stable system. This stable system will be minimally composed of the critical sub-systems and will produce better results with a higher degree of customer satisfaction and less stress for everyone involved. How: The person responsible for planning and leading the Software Integration Phase of a project reviews the list of suggested activities and behaviors. Select the items that reflect obvious past problems or possible current problems. Discuss some of the possible past problems with experienced team members while reviewing the list and identify these as Risk items. Identify the checklist items that will help in eliminating or reducing these risks. Add any team input to the checklist, as appropriate. Follow the activities suggested on the modified checklist. Software Integration and Planning Checklist Use the project WBS to do integration planning Review module and sub-module completion dates. Identify the core requirement modules and determine their dependencies from smaller or less significant modules and the interdependencies among the core modules. DonТt forget to cross-reference shared sub-modules. Review the available resources to balance workloads. Reprioritize resources to complete critical dependencies. Shuffle resources or add resources, if possible and necessary. Rethink contingencies and Уwhat-ifФ scenarios. What deliverables can be dropped or delayed or deferred until the future, if needed, when time is more critical than scope? Move these sub-projects to be the last deliverables to integrate in descending order of necessity. If the schedule pushes out, these will be the natural sub-projects to drop off the end and will ease re-planning. Evaluate and determine lab requirements and prepare the equipment and lab layout early Determine long lead items and reverse schedule them to make sure they are progressing at the needed rate and meeting the milestones. Determine long test or test equipment setup times. Identify critical equipment and space and reserve this ahead of time. Consider rearrangement of physical space or relocating personnel. Rules of Life Ц you never have adequate test equipment. Consider arguing passionately for the equipment your team leaders say is required. Determine if there are short-term options for providing more equipment on short notice. Investigate equipment rental terms and availability before you discover you needed it yesterday. Get Quality Assurance and Customer Service involved as early as possible Get QA (Test, SQA, Quality Control, etc.) and Customer Service (Field service, etc.) involved with doing testing earlier than they want. Have them participate at intermediate or early stages. This involvement lessons their later learning curve and they will know the project better during their acceptance and final testing. It also gives them a chance to establish contacts with the development teams before the development teams have all been moved to the next project. These groups benefit from the extra test time by learning the product and project better. The product and project benefit from their input earlier in the test cycles, lessening re-design because problems will be identified earlier. These groups gain invaluable УstreetФ knowledge by being in the lab with the developers while the developers are still working out problems. Rule of Life Ц There is no such thing as a Уhand offФ to the Quality group. Integration, testing, alpha testing and beta testing (or whatever your company calls itТs end game testing and integration phases) are continuous and in parallel (whether our WBS specifically calls it out that way or not). Drive assertively to meet each integration milestone on time, but especially the first one Push the teams to make each milestone, especially the first one, because it builds momentum for the team, forces a reality check on the validity of the integration schedule, helps set a Уcan doФ attitude later if the team runs into trouble, and builds confidence & self-esteem in the multi-discipline integration team thatТs forming. Be diligent on cross-functional team issues and cross-functional sub-projects. Do not allow Уthrow it over the wallФ behavior. Focus people on eliminating their domain area from the problem instead of pointing at other areas. Measure progress continuously and focus immediately on areas or sub-projects that start to lag behind the plan. Utilize and listen to the projectТs technical team leaders Good technical team leaders know their projects and their personnel. Utilize their insight and information and engage them in solving the cross-functional problems. Influence the team leaders to take personal responsibility for any and all milestones they and their teams are directly or partially responsible for. Remind the team leaders early that УdoneФ is not worked one time, once. УDoneФ is when the consumers of their work are content that it meets the requirements and has a reasonable expectation of being problem free. Be in the lab, be in the lab and be in the lab Be in the lab. It shows you care and that you are personally engaged. Be in the lab. It shows that integration is important and the people performing it have an important and valuable job. Be in the lab. If something starts to drift from the expected or there are any surprises, you will be there when itТs happening and have a higher degree of opportunity to take early action, rather than hearing about it days later at a status meeting. Remove obstacles. Find equipment. Help with setup. Go find necessary people. Schedule an unplanned system build. Get food and snacks when appropriate. Order equipment upgrades or gets equipment sent out for repair. Rent replacement equipment. Ask questions. Get answers to other peopleТs questions. Sit, watch and help with the testing. Provide a sounding board for people to talk out their problems or ideas. Display a high energy level and a positive, can-do attitude. Demonstrate through your actions and behavior that you care about what is happening and that what people are doing is important, necessary and valuable. Avoid a stall or slip Keep going through the Уtest and fixФ cycle with what you have available, while anticipating the next deliverables. Be flexible in giving people some leeway on personal Уcomfort zoneФ activities, like hand editing temporary files, jury rigging some test machine, short cutting some processes, etc. Never allow flexibility on unit testing before sub-projects get moved into integration. Insist on unit testing by the developer. To some extent, this minimizes subjective determination from the developer for УitТs only a small changeФ and УI didnТt change anything, exceptЕФ types of changes to slip into integration and cause unnecessary retrograde testing. Keep activity levels high. Keep people busy to keep their energy levels high during unplanned light times on the schedule. Retest core modules, retest modules that have changed or begin early testing for something about to begin. Know when to say УwhenФ When all critical, necessary and important modules are integrated, begin to shift focus to stabilizing the system. Consider dropping, delaying or deferring sub-systems that are not critical in favor of continued stabilization. A stable core system of required scope is difficult enough. Seriously review any and all new additions to the system as it stabilizes. Plan on being able to remove non-critical sub-systems that jeopardize the system stability. Prepare and evangelize management to buy into this mentality. Move the emphasis of the project team towards quality of what they have instead of adding and tweaking features and scope. Behave assertively, if needed, by instituting tight constraints on modifications and document control. Increase the control and influence of the quality department as the system stabilizes. Think and plan ahead Use what you have learned during this integration to smooth the post-integration phases. Use your lessons learned to accelerate the Quality Assurance, Alpha testing and Beta testing phases to minimize these teams having to learn or relearn lessons the Integration team has already overcome. Engage the project teams in assisting the post-integration teams and sharing knowledge and training, where necessary.     Software Integration Phase - Planning and Execution <C J ъ # М ▓  fБУк▄ўБШ╙Г╕joЯа═№4#5#М#&&]&░)▒)▀*:+█-▌-.+0Z0Е4Ы455.7/78/899ў9°95:6:;;o;p;Е;и<№їЁ№ЁчЁчЁрЁ╪Ё╪Ё╤Ё╪Ёч№ї№Ёї№╩№┴╖п┴╖п┴╖п╖┴╖п┴╖┴╖┴╖д╖д╖┴╖д╖д╖д╖д╖д┴╖hU5БCJOJQJhUOJQJhUCJOJQJhU5БOJQJ hU5Б6Б hU5БhhU5Б6Бh hU>*hhU5БCJh hUh hU5БCJhU@<К ъ ў m М ┌ ·┤+-|m╙╖kW0eа═№¤∙ўящщщщщщщщщщщщщ∙∙ўўў¤т & FдЁД╨^Д╨Д╨дЁ^Д╨дЁ!=i=¤¤№╬ !▓!5#М#$Л$═$&]&9($)▒)▌*▀*:+Й,m-▌-ььььх╥╥╥╥х┐┐┐┐╕хеее$ & F ╞h╨Д╨дx^Д╨a$$дxa$$ & F ╞h╨Д╨дx^Д╨a$$ & F ╞h╨Д╨дx^Д╨a$ & FдЁ$ & F ╞h╨Д╨дx^Д╨a$▌-.╛.T/+0Z0б012'272H2b2Ж2м2ь233@3f3п3ь3Е4Ы4°ххх°╥╥╥╥╥╥╥╥╥╥╥╥╥╥╥╥╥°$ & F ╞h╨Д╨дx^Д╨a$$ & F ╞h╨Д╨дx^Д╨a$ & FдЁЫ45/78/89°96:;p;Е;й<= =!=#=$=&='=)=*=,=-=ьььх╥╥╥╥╥х┐┐╜╜╜╜╜╜╜╜╜╜$ & F ╞h╨Д╨дx^Д╨a$$ & F ╞h╨Д╨дx^Д╨a$ & FдЁ$ & F ╞h╨Д╨дx^Д╨a$и<й<===!="=$=%='=(=*=+=-=/=0=e=f=j=Їът┘╒═╒═╒═╒═╒┬╗┬╗╒ hU5БCJhU5БCJOJQJjhUUhUhU5БOJQJhUOJQJhUCJOJQJhU5БCJOJQJ-=.=/=0=d=e=ўьўьlkd$$IfЦl╓╓0Ф юР$Zв╓0      Ў╓  ╓  ╓  ╓  4╓ laЎ $дx$Ifa$дx$Ife=f=g=h=i=j=ТРОООlkdТ$$IfЦl╓╓0Ф юР$Zв╓0      Ў╓  ╓  ╓  ╓  4╓ laЎ(░╨/ ░р=!░а"░а#Р╨$Р╨%░░ ░░ Р╨Р$$IfЦ!vh5╓Z5╓в#vZ#vв:V Цl╓0      ЎЎ5╓Z5╓в4╓Р$$IfЦ!vh5╓Z5╓в#vZ#vв:V Цl╓0      ЎЎ5╓Z5╓в4╓ЖЬH@ё H Normal CJOJPJQJ_HmH sH tH DAЄ бD Default Paragraph FontVi@є │V  Table Normal :V Ў4╓4╓ laЎ (k@Ї ┴(No List P■O1ЄP articlepara$дxдa$CJOJPJQJV■OV Caption figure$дЁдxa$5БOJPJQJR@R Header,Evenдx ╞р└!CJOJPJQJH @"H Footerдx ╞р└!CJOJPJQJ2B@22 Body Textдxj5 P    <КъўmМ┌·┤ + - | m╙╖kW0eа═№╬▓5МЛ═]9 $!▒!▌"▀":#Й$m%▌%&╛&T'+(Z(б()*'*7*H*b*Ж*м*ь*++@+f+п+ь+Е,Ы,-//0/01°1623p3Е3й45 5!5#5$5&5'5)5*5,5-5.5/505d5e5f5g5h5k5Ш0ААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0АААШ0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0 ААШ 0 ААШ 0 ААШ 0 ААШ 0 ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ 0ААШ0ААШ0ААy╚0мyИ0Яy╚0мyИ0Яy╚0мyИ0Яy╚0мyИ0Яй@0АА╨ й@0АА╨ Щ@0АА╘ й@0АА╨ й@0АА╨ Щ@0АА╘ Ш@0ААy╚0мyИ0DЯ GGGGGJи<j=%№▌-Ы4-=e=j= "#$&'i=! 5!5!5#5#5$5$5&5'5)5*5,5-5.5.5d5d5h5k5эЇ\ e $8ї !S"W"!5!5#5#5$5$5&5'5)5*5,5-5h5k533333!5!5#5#5$5$5&5'5)5*5,5-5h5k5                     ДhДШ■╞h^Дh`ДШ■. ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё ДhДШ■╞h^Дh`ДШ■OJQJo(╖Ё                                                хU!}Z!5#5&5)5,5.5/505d5e5f5k5    ЮЦ @Аu┴юР$j5└@  Unknown            GРЗz А Times New Roman5РАSymbol3&Р Зz А Arial3РУTimes"1ИЁ╨hьФrF╗KЖfю3-`ю3-`!Ёе└┤┤А4d55Ё▀▀HXЁ ?ф                     !}Z2  2Checklist: Integration Phase Planning & Execution Peter Michelsthe balfour group4         ■ рЕЯЄ∙OhлС+'│┘0ЬИР╠╪Ё№ ,8 X d p|ДМФф4Checklist: Integration Phase Planning & ExecutionPeter Michels Normal.dotthe balfour group6Microsoft Office Word@╥Ik@ЁvC2╫┬@┬z▐M─ю3-■ ╒═╒Ь.УЧ+,∙о0 hp|ДМФ Ьдм┤ ╝ √ф`5G 3Checklist: Integration Phase Planning & Execution Title  !"#$%&'(■   *+,-./0■   23456789:;<=>?■   ABCDEFG■   IJKLMNO■   ¤   R■   ■   ■                                                                                                                                                                               Root Entry         └F@ЛЪШ▐M─TАData             )1Table    1VWordDocument    *PSummaryInformation(            @DocumentSummaryInformation8        HCompObj            q            ■                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           ■       └FMicrosoft Office Word Document MSWordDocWord.Document.8Ї9▓q