The New CIO for Rose Industries

BACKGROUND

Rose Industrieswas a manufacturer of electrical products for the home. A large portion of its business base was devoted to the design, development, and manufacturing of specialized electronic components for public and private-sector clients.

Ralph Williams had been with Rose Industries for more than 45 years, beginning in the mail room and working himself up to president and chief executive officer (CEO) of Rose. He was now beginning his tenth year as president and CEO.

Rose Industries believed in inbreeding. All promotions were from within the ranks. Rose often had trouble attracting talented people, especially people with degrees, because the company's conservative policy dictated that all new employees begin at the bottom of the company and work their way up. Every senior manager at Rose had been with the company for at least 30 years. Rose Industries discouraged employees from taking outside seminars and courses. If you wanted to attend a conference or symposium, the policy was "Take vacation and pay your own way." There were several training programs available to the workforce, but they were all taught by internal personnel and covered only the skills needed to do each job more effectively or to become qualified for a promotion to the next pay grade. Each employee was allowed a maximum of seven days off a year to attend internal training programs.

The company did not have any tuition reimbursement policy. Numerous colleges and universities in the surrounding area provided a variety of evening programs leading to various certifications as well as undergraduate and graduate degrees, but employees had to pay all expenses out of pocket. In order to satisfy some of the needs of the employees at Rose Industries, many of the professional societies in the surrounding area held conferences, symposiums, and professional meetings on weekends rather than weekdays.

A TIME FOR CHANGE

By 2003, the ultraconservative nature of Rose Industries began to affect growth. Rose was falling farther behind its competitors, and gross sales were declining rather than increasing. Although Rose was considered a low-cost manufacturer, it was losing business to some higher-priced competitors whose advertising campaigns attacked Rose's weak project management capability. For years, Rose could not see any value in using project management and seemed to discourage its personnel from becoming a Project Management Professional (PMP). Project

management was never identified as one of Rose's strengths in its proposals during competitive bidding. Rose did use a few templates when managing projects, but no formal project management methodology existed.

Rose's information systems were somewhat outdated. When software was needed, especially for more sophisticated business requirements, Rose would look for off-the-shelf products even though the products were not 100 percent applicable to or did not satisfy all of the company's needs. Rose did maintain an Information Technology Department, which would create software for smaller requirements, but no systems development methodology was used.

HIRING THE CIO

Ralph Williams, president and CEO of Rose Industries, understood quite well the seriousness of the situation. The company must become good at project management, improve its information system, and develop methodologies for both project management and information systems. Mr. Williams decided to break with tradition and hire a new chief information officer (CIO) from outside the company.

After an extensive search and interviewing process, the company hired John Green, a 20-year veteran with one of the largest IT consulting companies in the world. There was no question about John's credentials and what he could bring to Rose Industries. The real issue was if and when he would be able to change the culture to accept his new ideas. Rose Industries had the same culture for decades, and getting the seasoned veterans at the company to accept change would be difficult. John was told about the challenges before he was hired, and he felt that he could adequately handle the situation.

A BULL IN A CHINA SHOP

During the first two weeks on the job, John interviewed personnel from all levels of the organization to ascertain how difficult it would be to change the culture. The situation was worse than he had been led to believe.

John knew from decades of experience in project management that there are four characteristics of an effective project management culture: communications, cooperation, teamwork, and trust. The interviews made it quite apparent that there was no project management within the company and senior management had been reluctant to initiate improvements. Communications were quite poor because of the lack of a good information system. Cooperation and teamwork occurred only if people felt that they could benefit personally. There was more mistrust than trust. The building blocks for effective project management simply were not there.

John originally thought that he could make the necessary changes within two years. Now, after the interviews, it looked like five years would be closer to the truth. If this five-year time frame were allowed to happen, the health of Rose Industries could significantly degrade during that time period.

John came up with a four-step approach for implementing change:

Step 1: Hire several PMP credential holders quickly.

Step 2: Create two project management offices (PMOs); one would function as an IT PMO, and the other one would be a corporate or strategic PMO.

Step 3: The IT PMO would create an IT systems development methodology suitable for Rose Industries

Step 4: The corporate PMO would create an enterprise project management methodology

for all of Rose's projects except the project in IT. The PMO would also participate in the portfolio selection of projects, strategic planning for project management, and project risk management activities.

John believed that this approach could accelerate the maturity in project management and some good practices could be in place in about two years. All he needed now was buy-in from the executive staff for his plan.

PRESENTATION OF THE PLAN

At the next executive staff meeting, John presented his plan. The responses were not what John had hoped for. The other executives in the room immediately attacked step 1, arguing that they had no intention of hiring additional people.

John would have to get some of the existing labor pool personnel trained in project management. When step 2 was addressed, the executives argued that creating two PMOs would be the same as adding layers of management on top of the existingorganizational structure. They simply could not see the need or value in having PMOs and viewed them as possible threats to their power and authority.

When step 3 was discussed, there were several questions as to why Rose Industries had to develop its own systems development methodology when several packages were commercially available. Some executives seemed to have no idea what a systems development methodology was or why it was needed at all.

When step 4 was discussed, the executives became furious that John was recommending that someone other than the executive levels of management participate in the portfolio selection of projects, especially project managers who were not even on a management career path ladder. The portfolio selection of projects was obviously seen as a job done entirely by executives. Likewise, allowing anyone other than executives to be involved in strategic planning and risk management was as a serious threat to some executives who perceived that this could impact their power, authority, and bonuses.

John now saw quite clearly what he was up against and that all of the executive support that he was led to believe would be forthcoming would not happen. However, within two weeks after the meeting, John decided to accept the challenge. He moved forward by forming his project team fromexisting labor pool personnel and creating just one PMO. On the other side Rose Industries executive team approved to reduce the scope to just IT systems development methodology for the first phase.

B:

The New IT PMO for Rose Industries

Mr. John Green, the new CIO of Rose Industries, is going to start his journey by setting up the new IT PMO. The whole process of designing and establishing a PMO especially in a company like Rose Industries where a PMO does not exist is a new concept and can appear to be a very big and challenging project itself. John strongly believes that creating a project for the designing, establishing, and implementing of a PMO is considered a best practice, which will maximize the outcome and will be the first step toward the company's long-term plan toallow the project management maturity of the organization to grow.

However, the ultra-conservative culture of the company and executive committee recruitment of forming the project team from existing labor pool personnel can add extra complications and challenges.

In the early stage of planning, John identified some of the key aspects of the work to be:Hiring project team, Job redesign, Project Management training, people change management,PMO organization, procedure development, process redesign,management reporting,androllout plan for implementation.

-End of Case Study

Assume you are CIO (John) and you're getting ready for the first planning meeting with your team. You know how important it is to select the right development methodology for the project. You are going to debrief your team on the decision you've made.

2^nd Topic / Group 6 - You believe Waterfall is the best development methodology to use for the IT PMO project. A presentation that highlights why you believe Waterfall is the best choice in this situation.

Background

What is Waterfall?

5 Stages of Waterfall

Advantages and Disadvantages of Waterfall

These are the rough points created by the team for the ppt can you please expand this for me, So that I can make the ppt?

I am attaching the relevant part of the textbook instruction on agile and waterfall for your reference.

5. Project Planning Overview After the project has been approved and the project team has been appointed, you are ready to enter the second phase in the project management life cycle: project planning. This phase involves creating a set of plans to help guide your team through the execution, monitoring, and closure phases of the project. The plans created during this phase will help you manage time, cost, scope, quality, changes, risk, and other related issues. They will also help you lead staff and work with external suppliers to ensure that you deliver the project on time, within budget, and with the desired feature/functionality. The planning phase is often the most challenging phase for a project leader because they must make educated guesses about the staff, resources, and equipment required to complete the project. In collaboration with the project sponsor(s), the project leader identifies the work to be done for the project or the iteration (depending on the development methodology used). Once the major components of the project (or iteration) are known, the project leader will identify team leaders to carry out the detailed planning of the project's sub-components. These components are often called "work packages" in predictivemethodology and "sprints" in agile's adaptive methodology. Also, at this stage, resource requirements are identified in whole or in part (depending on the development methodology used). A strategy is developed for accomplishing the work. Then, the timeframes, dependencies, and resources required for work packages or sprints are documented in a project schedule. In addition, the project leader coordinates the preparation of a budget by providing cost estimates for the labour, equipment, and materials. The budget is monitored during the implementation and closure phases. Once the project team has identified the work, prepared the schedule, and estimated the costs, the three fundamental components of the planning process are complete. This is an excellent time to identify and try to deal with anything that might pose a threat or an opportunity to the successful completion of the project. This is called risk management. In risk management, the threats and opportunities are identified along with the action that is to be taken as a response in order to optimize the likelihood of project success. In the initiation phase, a preliminary list of project stakeholders was identified. During the planning phase, the list is reviewed to ensure that it remains current and stakeholders continue to be prioritized. Stakeholder engagement is a critical success factor. An effective communication plan is one of the tools used to ensure stakeholders remain informed and supportive of the project's objectives. Effective project leaders spend about 90% of their time on a project communicating with stakeholders.1 In some instances, organizations need to obtain products and utilize services from outside of the organization. Overseeing these transactions is known as procurement management. During the planning stage, it involves identifying the type of vendors required and the selection criteria to be used. Finally, project leaders ensure that the team understands the quality expectations of the stakeholders. In order to fulfill these expectations, a quality management plan is developed (identifies quality targets, assurance, and control measures), along with an acceptance plan (lists the criteria to be met in order to gain stakeholder acceptance). The project leader integrates the team's planning efforts. Various tools and techniques are used to effectively perform integration management. A comprehensive project plan may be created to ensure all the various management plans identified above are cohesive and well-aligned. Project plans are typically created for projects with a medium-to-high level of complexity and rarely for low complexity projects. Determining the need for a project plan is part of the tailoring work done by the project leader at the outset of each new project. The planning phase refines the project's objectives, which were identified during the initiation phase. This phase also includes planning the steps necessary to meet those objectives by further identifying the specific 52 | 5. Project Planning activities and resources required to complete the project. Once the objectives have been fully recognized, they must be clearly articulated, specifically detailing in-depth scrutiny of each objective. When viewed under such scrutiny, the team's understanding of the objectives may change. Often, the very act of describing something precisely allows us to better understand its scope. This articulation serves as the basis for the development of requirements. What this means is that, after an objective has been clearly articulated, it can be described in concrete (measurable) terms and the steps to achieve it are easier to identify. Obviously, if a poor job is done of articulating the objectives, the requirements will be misdirected, and the resulting project will not represent the true need. 1.1 Eliciting Project Requirements After the objectives of the project are identified, the project leader needs to better understand the solution's requirements. Requirements describe the characteristics of the final outcome, which may be a product, service, or result of the project. Moreover, requirements describe the functionality that the final outcome must possess and specific conditions that must be met in order to satisfy the objectives of the project. It is important to start defining requirements at the project level. Project requirements describe what the project is supposed to accomplish. This gives the project team a clear understanding of the required outcomes and their corresponding organizational value. These outcomes often describe the transformation that will occur within the organization as a result of the project's implementation. A clear picture of the current state (the "asis") and the desired future state (the "to-be") is an effective way to help the team determine what the solution must achieve. Teams that lack an understanding of the project requirements are unlikely to deliver solutions that provide organizational value. Solution requirements are developed after the project requirements. When the adaptive development methodology is used, the requirements are developed in an iterative or incremental fashion. As previously mentioned, in agile, solution development begins with an epic, which are the rough outlines and boundaries of the solution. The end-user community is involved in numerous requirement development sessions. These sessions determine the required capabilities, enablers, and features of the solution. Features are written as user stories which are then compiled in a product backlog that becomes the basis of iteration planning. The iterations are referred to as sprints, each containing a set of requirements that guides the development and testing efforts. In contrast, when the predictive development methodology is used, the end solution is clear, allowing the requirements to be completed upfront. The end-user community participates in far fewer requirement development sessions than when an adaptive approach is used. In general, solution requirements may include attributes such as dimensions, ease of use, colour, specific ingredients, and so forth. Requirements must be measurable, testable, related to identified organizational needs or opportunities, and defined to a level of detail sufficient for solution design. The Nature of Requirements When developing a solution, many different aspects must be considered. At the simplest level, the project team will seek to understand how the end-user community expects the solution to function. In addition, the project team must determine how this functionality will be delivered through technology and related systems. Lastly, there may be regulatory or industry-specific requirements that require consideration. 5. Project Planning | 53 The End-User Community Solution requirements start with the end-user. In fact, project success is dependent on a clear understanding of the end users' needs. When project teams identify the end users' functional requirements, they are focusing on the user experience with the new product, service, and/or result. End-user requirements can be written as user stories that describe what the user wants the solution to do and how the solution should perform. This allows the project team to understand which features are valued and therefore required, by the end-users. When the needs of the end-user community are considered in solution design, the project team can begin to narrow down the potential design alternatives. Further, the needs of the end-users help identify which quality expectations must be fulfilled. Technical Requirements Technical requirements emerge from an understanding of the end users' requirements. Functional requirements provide answers to questions such as: how will the problem be solved this time, and will it be solved technologically and/or procedurally? These requirements specify how the system must be designed and implemented in order to provide the required functionality and fulfill quality expectations. For example, in a software project, the functional requirements may stipulate that a database system will be developed to allow access to financial data through a remote terminal. The corresponding technical requirements would spell out the required data elements, the language in which the database management system will be written, the hardware on which the system will run, the telecommunication protocols that should be used, and so forth. Similarly, end-users may require the solution to be functional and accessible 95% of the time. The technical requirements will identify how this will be done using backup power supplies and so forth. Regulatory or Industry-Specific Requirements Regulatory requirements are rules that are mandated by the government. For an example of a regulatory requirement, privacy and the protection of confidential client/customer information are extremely important to consider for projects in a variety of industries due to strict laws imposed by parliament. Regulatory requirements can be very industry-specific, which, as previously mentioned, is beyond the scope of this textbook. Elicitation Techniques Although the project leader is responsible for ensuring that the requirements are clear and well documented, they usually do not perform this work. The approach taken varies considerably depending on the chosen development methodology. Key differences include the roles responsible for requirement development and the number of sessions held throughout the project. Predictive (waterfall) development methodologies define solution requirements upfront. As a result, fewer requirement development sessions are necessary. In contrast, when the adaptive development methodology is used, a product owner works very closely with the project leader to plan the number and nature of the sessions required. Despite these differences, some of the information sources are similar. For instance, the following documents are often reviewed: Process flows for the "as is" environment Policies and procedures Problem/issue logs (including customer complaint logs) 54 | 5. Project Planning User cases/stories created for technological implementations Although documents can be helpful, they are often incomplete. It is important to consult with end-users directly. This direct consultation may involve discussions with employees who represent the voice of the end customer as well as the end customers themselves. The following techniques can be used: Interviews Focus groups Facilitated group sessions Group creativity techniques, such as: Brainstorming Mind-mapping Observation of clients, customers, and/or end-users Questions and surveys Group decision-making techniques, such as: Seeking consensus (among experts, the project team, the end-user community and so forth) Majority rule voting Dictatorship (project sponsor or product owner decides) An important note about adaptive development approaches: prototyping is a common method used to identify requirements. It allows stakeholders to experiment with an evolving model of the final product and/or solution. This is very helpful because many stakeholders find it challenging to verbally explain or write down their needs. Seeing how things work may help them articulate their needs. Additionally, a prototype allows the project team to measure the product and/or solution's functionality and performance in a more realistic way. Once assessed, the prototype can be refined based on any revelations learned. Requirements Traceability Matrix Keeping track of the requirements is important for many reasons. Firstly, tracking the source of the requirement is helpful in resolving issues of prioritization. It may not be possible to develop a solution with all the requested requirements due to a lack of feasibility, time, and/or money. Consultation with stakeholders becomes critical in these situations. In addition, difficulties may arise during development, requiring the input and review of specific stakeholders depending on whether their requirements have been affected. These situations underscore the importance of knowing which stakeholders have requested which requirements. There is an arguably more important reason to track requirements; it ensures that each requirement can be efficiently traced back to the objectives of the project. This allows the team to constantly reflect on whether specific requirements add value.

An effective requirements traceability matrix includes the following information: Requirements to organizational value and project objectives High-level requirements to more detailed requirements Requirements to project scope/work breakdown structure Requirements to product/service design Requirements to product/service development Requirements to test strategy and test scenarios Additionally, attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about each requirement. Typical attributes used in the requirements traceability matrix may include a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved), date completed, and acceptance criteria, which ensure that the requirement has met stakeholders' satisfaction. Once the requirements are documented, the appropriate stakeholders sign off to confirm their needs have been accurately recorded. The project leader then ensures that the requirements are incorporated into the overall project plan (for predictive approaches) or iteration plans (for adaptive approaches). The effective specification of requirements is one of the most challenging undertakings tackled by project teams. Inadequately specified requirements will guarantee poor project results. Excellent communication and negotiation skills are critical as project leaders often need to educate stakeholders about the organizational impacts and implementation complexity of some of their requirements. In addition, when elaborate requirements introduce additional complexity in a project,more staff, time, and/ormoney may be required. The added complexity may also have an impact on project quality. Furthermore, some aspects of the project may be unfeasible. If this is the case, there must be transparency with stakeholders so they can adjust their expectations and/or prepare for future organizational challenges. 5.2 Scope Management Requirements assist project teams in making scope decisions. During the initiation phase, the scope is often broadly defined. High-complexity projects are more likely to have broad definitions of scope, describing the desired outcomes of the project, since the availability of information regarding the solution may have been minimal. However, as more information is obtained, the scope begins to be further refined in the planning phase. Scope statements identify the product and project deliverables that will be produced during the project or the iteration. Deliverables are tangible outcomes that must be produced created in order for the project or the iteration to be completed. This includes the project management deliverables and the product/service/result deliverables, which are features that characterize the solution. In essence, the project scope denotes what work will be done whereas the other project plans denote how the work will be done. 56 | 5. Project Planning When the predictive/waterfall development methodology is used, a scope statement representing the full scope of the project is created. Then, the development team uses this scope statement to design and develop the end solution in its entirety. When the adaptive development methodology is used, all the user stories contained in the product backlog represent the scope of the project. The development team does not work on the entire backlog at once. During iteration planning, the backlog is prioritized into small "sprints." The scope of these small sprints usually represents a few weeks of development effort. The results of each sprint are reviewed with the end-user community and adjustments are made as appropriate. The scope of the sprints may change as the team learns more about the end users' requirements and the effort required in each sprint. One of themost common challenges in projects following a predictive (waterfall) developmentmethodology is the unintentional expansion in the project scope. This is referred to as scope creep. Sometimes this occurs because the scope was poorly defined at the onset. Perhaps the scope statement was poorly developed and/ or lacked the necessary stakeholder input and approval. Furthermore, the project team may have chosen the wrong development methodology. For instance, if the team knew that the outcome of the project was unclear and chose the predictive (waterfall) methodology regardless, scope management will prove to be very challenging for the project team and stakeholders. This is because the stakeholders are likely to advocate for the preservation of timeline and budget commitments. This leaves the project team with the chaotic task of figuring out how to deliver on these commitments while the scope remains fluid. This is not to say that scope should never be expanded. The key is how the scope is changed. When scope changes are analyzed and formally approved (versus automatically or unintentionally pursued), project leaders can determine the impact of this change on the project's timelines, budget, and quality constraints (recall the triple constraints theory). Communicating the impact of scope expansion on these constraints allows stakeholders to make effective decisions about project priorities. Work Breakdown Structure The work breakdown structure (WBS) is a powerful communication tool. It is a visual depiction of the work (scope) to be completed during a project by breaking the project down into smaller, more manageable components. When the predictive (waterfall)methodology is used, a deliverable-orientedWBS is often used to identify the relationship between the deliverables, sub-deliverables, and, ultimately, the work packages associated with the project. Each level of theWBS hierarchy represents amore detailed breakdown of the project work wherein the top of the hierarchy represents broad categories and the lower levels represent increasing amounts of detail, with work packages always being the lowest level of the WBS. Some project teams prefer to use a phaseoriented WBS to depict the deliverables of each phase. For instance, the phases could be initiation, planning, development, testing, rollout and closure. Both are acceptable forms of the WBS. The project leader is free to determine the number of levels in the WBS based on the complexity of the project. It is important to include enough levels to accurately estimate project time and costs, but not so many levels that it becomes too detailed and difficult to read. When an adaptive methodology such as agile is used, the WBS depicts the relationship between the project (an "epic"), the capabilities of the solution, the features/enablers of the solution, the user stories, and the sprints that contain the development teams' tasks. It is very important to note that the WBS defines what needs to be done, not how. The how is developed by the work package leaders once the WBS has been completed and it is depicted using tools like the project schedule and project budget. A WBS can be structured in a graphical form where boxes represent the major deliverables, sub deliverables and work packages. The individual boxes cascade in a hierarchy, illustrating the relationship of the underlying 5. Project Planning | 57 work. Exhibit 5.1 depicts the WBS language used in predictive (waterfall) and adaptive (specifically agile) methodologies. Exhibit 5.1: The WBS for Predictive and Adaptive development methodologies. In predictive methodology, the sequence is as follows: project, major deliverables, sub-deliverables, and work packages. In the case of iterative/agile methodology, the sequence is: project (may be referred to as an 'epic'), capabilities, features/ enablers, and sprints. It is also possible that the list format is used. This format simply lists the deliverables and the underlying work in a list format. The list format below uses terminology from the predictive methodology.

Each level of aWBS can be assigned a unique identifier. This unique identifier is typically a number that is used to track costs, durations and resources associated with WBS elements. These identifiers are usually associated with an organization's chart of accounts, which is used to track costs by category. In addition, these identifiers are often referred to in a project schedule and a project budget as this allows the project team to ensure all the project work has been properly scheduled and resourced. Work packages and sprints are components that are easily assignable to a team of people, providing clear accountability and responsibility for detailed planning and ultimately implementation. It is important to ensure that individuals with the appropriate skills, experience, and capacity are assigned to manage the delivery of this work. They collaborate with the appropriate stakeholders to: 1. Confirm who must be involved in the work 2. Identify the tasks to be performed 3. Create a detailed schedule for the tasks, including identifying all the required resources, durations, sequencing, and key monitoring points for measuring success. 4. Identify the cost of completing the work 5. Identify specific assumptions, risks, and issues The project leader compiles the work of all work package/sprint teams in order to produce integrated plans for the project as a whole. Project leaders often discover situations where the schedules and budgets are in conflict with stakeholder expectations. When this occurs, the project leader gathers the appropriate stakeholders (e.g. scrum master and product owner[s] in cases where adaptive methodology has been used). The project leader then facilities alignment with the stakeholders and the project's objectives. The upcoming sections on schedule management, budget management, risk management, and stakeholder management will delve deeper into these important aspects of project management.

You believe Waterfall is the best development methodology to use for the IT PMO project. A presentation that highlights why you believe Waterfall is the best choice in this situation.

Background

What is Waterfall?

5 Stages of Waterfall

Advantages and Disadvantages of Waterfall

Please expand these rough points for ppt