Case studies in project, program, and organizational project management.

Project Anatomy: Joakim Lillieskold and Lars Taxen

All questions on Page 98

What are the answers to this case study, please?

1. Explain the purpose(s) of project anatomy.

2. What are the disadvantages of project anatomy?

3. What are the differences between the project anatomy and the WBS? Is it any better? Why/why not?

Project Anatomy Joakim Lillieskold and Lars Taxen The project was heavily delayed. The new project management team was trying to grasp hold of the situation. The scope of the project was clear: Develop a new central processor for the AXE system. The processor was to be state-of-the-art, It would mean a lour-lime increase in capacity of the system in terms of speed, bandwidth, and quantity of transmission. Further, the processor included new capabilities, new mechanics, new firmware, a new real-time master and slave ASIC, lower electrical consumption, and a reduction in size and weight. At the moment, the risk analysis showed the project would be a nightmare. There was no simulator that could manage the ASIC. As a matter of fact, several of the large ASIC-producers could not support the development project at all. It was consid- ered the most advanced and complex ASIC ever developed! Ifa fault was found in the ASIC, it would take three months to get a new one, and thus delay the project by the same amount of time. There was no room for mistakes. ORGANIZATION The project was called The Central Processor. The project was huge, and consisted of seven major smaller projects, several of which also consisted of subprojects. The development of those smaller projects was dispersed according to the loca- tions of the core competences. When activity was at its peak, about 300 people were involved in different projects located in seven different places across three countries and two continents (Sweden, Germany, and Australia). In addition, the project also used external consultative resources to a great extent. The project was challenged by cultural differences, especially the corporate cultures. Many engineers in the project had been employed for 20 years or more in the same organizational setting. But at the time of the project, the company began to reorganize. Personnel from fixed telephone networks, mobile networks, and military networks each having different and quite embedded management styles and different approaches to system development were moved between the business units and would now have to cooperate with each other. The reorganiza- tion also implied that many managers came from other parts of EXT, a leading 92 Project Scope Management 93 provider of telecommunication and data communication systems, into this project. This reorganization included a new CEO for the business unit where the project was located. PROJECT RE-PLANNING In the middle of the project, there was a change of personnel in key positions. The project had just passed Tollgate 2, which was the point in the EXT project model, where the decision is made to cither go ahcad or not. At this point, the organization realized that the project would be heavily delayed compared to the estimates in the prestudy. When the new project manager of the critical CPG (one of the seven major projects) entered the team, it became clear that there was no control over the project status or when things should be done. As an effort to get involved in the project. At the same time, there were rumors about a new approach to the bottom of the problem, the new project manager started to interview people used in an earlier project at EXT: The Japan Project, when EXT became the first foreign supplier to get a foothold of the Japanese market for mobile systems. The company had painfully learned from earlier projects that: When managing complex projects, there is a need for a general picture." The approach used in the Japan Project provided such a general picture: the anatomy, Supported by the new management that had experience from the Japan Project, the CPG project manager got the go-ahead to try the same integration- driven approach as in the prior project in order to get things back on track. This approach was based on the anatomy and consisted of three phases: definition of the anatomy, dividing the development task into verifiable increments, and inte- gration of those increments. THE ANATOMY An anatomy is created from the customers' point of viewin this case, the end customer, being the one using the final system as opposed to the internal customer ordering the project. The starting point in creating the anatomy begins by asking the questions: "What is the first thing customers do? The next? And the next? What do they expect out of this product? What is the end result?" The anatomy illustrates the dependencies between the capabilities the system must have; from switching the power on to getting out a stack of bills that can be sent out to customers. CREATING THE ANATOMY In the central processor project, crcating the anatomy required about seven moct- ings. Each meeting included, at the most, 12 persons, but throughout the process more people were involved. The people who took part in creating the system 94 CASE STUDIES anatomy were line managers, and people with knowledge regarding the system (system integrators, system leaders, product managers). Informal group leaders were included as well. These people had a mix of hardware and software skills. Everyone involved was not active all of the time: some had knowledge of the start-up capabilities and some of other capabilities. There were many discussions over where the anatomy ended. However, the important issue was to create a common understanding of the final system solution, and to understand each others "language." INTEGRATION AND PROJECT PLANNING CPG project manager: When we agreed what capabilities to deliver and how they depended on cach other, we could take the next step to organize the work and create a plan for the work, First we did the anatomy, then the organic integration plan, and last, the integration and project planning. These latter two were not made within the same group of people that created the anatomy. In this process, the project manager was in charge. The focus of this process was to be able to test and integrate the system as early as pos- sible and to also deliver to the customer as early as possible in order to avoid further delays. The organic integration plan, as I call it, is when we try to organize the capa- bilities from the anatomy into suitable increments. We decide how long it will take, the number of test channels, ctc. It is a lot to take into consideration, and personnel from system integration and verification are important to include in this task. The integration plan is similar to the organic integration plan, the difference is that time is included in the integration plan CPG project manager: In this project, we flipped the integration plan so it went from left to right, like any other project plan. The reason was that it was difficult to get all the information into one picture, and then it worked better to flip it around. It is important that the images are explicit and intuitive to understand. The anatomy focused on capabilities. However, when these capabilities were transferred to the integration plan, the increments were referred to as something directly related to what they should do. Sometimes, a larger system's name was put into the integration plan, even though only a small capability of the system was going to be used. This, however, helped people to recognize themselves in the integration plan. Project Scope Management 95 When the integration plan was created, it served as thy basis for a tollgate decision to go on with the project. If there was a change in the project, or the customer wanted to pay less, it was casy to cancel an increment or capability, and still know how this affected the rest of the system. THE LEARNING By restarting and implementing the anatomy approach, the new management felt they could take control of the project. CPG project manager: Before we drew up the integration plan, we thought that RPH (a subproject) was delayed, But then we saw that we did not need their output until a later date. In fact, they were perfectly on time. In other words, we had a different opinion about the dependencies in the project. It was the micro-programming which was wrong, totally wrong. They didn't even have the resources they needed in the project at that point in time. So they had to reschedule everything they had to do. This is an obvious effect of the anatomy work. It wasn't until then we saw how late we were. When doing the anatomy, we realized that we would be late anyhow. By implementing the approach, several other issues surfaced that needed to be addressed as well. Some of these are implicit in any project, but they became painstakingly clear when this method was applied. RESISTANCE TO CHANGE Change, however, does not come easy. The initiatives of the new management were interpreted as a devaluation of previous experience by senior engineers. On the other hand, new engineers and newcomers in the project organization approved it. And most importantly, the new CEO liked it because the status of the project became very clear . The resistance though led to frustration from both the new managers and the engineers that stemmed from the proud traditions of AXE development. There were many who said: "We have been developing the APZ processor for 20 years. We know our work. People from other parishes should not come here and tell us how to do our job. It is possible that these methods have worked clsewhere, but our work is a specific case." The anatomy enforces a certain mindset: "What is the first thing the customer docs when he starts up the system? Push the start button! This mindset is on the principle that a system should be developed in the same order as it comes to life." This principle was somewhat hard to accept for some designers: "I'll design this function later, I'll start with the most difficult and interesting) things first." 96 CASE STUDIES Some actors experienced the anatomy as a threat to their professional knowl- edge: "It can't be this bloody insignificant; I'm actually doing more difficult stull" implying that their dillicult everyday tasks were dwindled down to a mure functional box on the anatomy chart. Others claimed that they could not even see their particular contribution and context in the anatomy. Thus, in order for the anatomy to be accepted by the actors it is important that it is defined in such a way that cach actor can see both his context and place in the overall picture. CPG project manager: What we missed in the CPG project was the ability to split the anatomy into smaller parts so that individual designers could under- stand where they participated and where they didn't. MAKING SENSE CPG project manager: Some continued drawing up the anatomy chart for two months ... In one case pertaining to a mature product; people could not agree (how the product worked) even though they have been working together and across the same corridor for 20 years. These engineers had differing views of how the system actually worked. During the process of creating the anatomy, the crucial dependencies had to be articulated and agreed upon. For that specific system, it was the first time they discussed which were the crucial capabilities in the system and the interconnections between them. CPG project manager: It is about creating a common image and not about having a 200-page document in English needed to be equally understood by all, regardless of being Swedish, German, or Japanese. The most important quality of the anatomy is that it enables the actors to see their task in relation to other tasks. This is achieved by a visual picture which is prefer- ably drawn on one page. Based on this picture, they can take the proper actions to achieve a common goal. No sophisticated tools are necessary. Mostly. PowerPoint is used since it is easy to learn and commonly available, PROJECT PLANNING AND CONTROL Hardware engineer: It is an extensive architectural change we are now approaching, involving a radically new approach. It is probably the largest step that has been taken when it comes to AP7 processors. The task of developing a central processor demanded a scheme where subtasks (i.c.. the development of subsystens) needed to relate to cach other as both input and output, implying a reciprocal interdependence. As such, the interrelated Project Scope Management 97 parties needed to communicate their requirements and respond to cach others needs. The central processor also had 29 different external dependencies for various communication systems that needed to be considered during the devel- opment effort, making it complex and difficult to manage. Hardware engineer: In this project, we have really been exposed to the gen- cral problem of development work: The fact that it has not been done before makes it impossible to know for sure how to do it and how long it will take. In the project, no network plan or Gantt chart was used at the top level. The expe- rience was that network diagrams were too time-consuming to update in projects where frequent changes were the order of the day. Thus, in order to plan and con- trol the project, there was a need for two types of plansthe integration plan based on the anatomy, and the ordinary project plan (time and resource plan) for each increment which provided the necessary logistics for the execution of the project. COMMITMENT AND RESPONSIBILITY Commitments and responsibilities are important aspects when coordinating a complex development project. The anatomy provides a "push and pulls concept which makes these aspects clearly visible. There is a receiver for every delivery in the project, including the customer. If a subproject is delayed, this becomes very evident, something that wasn't always appreciated in the CPG project. CPG project manager: When you did progress control based on the anatomy it became very clear who was slacking, which was not very popular among many people. It became so evident on the map and that could be hell. But it was the truth. Thus, the anatomy made commitments and responsibilities more transparent, which in turn made it easier to control the progress of the project. Concerning progress control. it is easy to show progress and problems with the help of the anatomy. A simple system of cues can be utilized for signifying progress, for example, traffic light signals. CONFIGURATION MANAGEMENT A drawback to the integration-driven method of working is that it is complicated for the system manager. Before, the PROPS model had milestones that were con- sidered well defined. Now, some of these milestones could not be reached until every subproject had met its milestone, resulting in the passing of many sub- projects' milestones at the same time. Even further, configuration management of the project became more complicated, 98 CASE STUDIES CPG project manager: It becomes a bit messy and requires a very competent configuration manager. That particular person acquired a higher status since he/she had to keep track of partial deliveries. This, in turn, requires a tool supporting configuration management, and, if the pro- ject is very complex, a tool to keep track of all the increments and dependencies. Discussion items 1. Explain the purpose(s) of project anatomy. 2. What are the disadvantages of project anatomy? 3. What are the differences between the project anatomy and the WBS? Is it any better? Why why not