CIOs usually have a pretty good view of the corporation and understand how processes work. Are CIOs better able to effect these types of business management changes compared with other executives?
HAMMER: In general—there are exceptions to everything—the CIO is not in a position to drive and lead this effort. It can only be done by a senior, business-line executive. But the CIO is extremely well positioned to be what I call a catalyst, where the CIO—because IT sits outside the various functions—really has a bird's-eye perspective on the process issues in the enterprise. In fact, a lot of these process issues often show up in systems terms. And the CIO can really be the catalyst to alert senior executive management to the problems with processes and to the opportunities that process management presents. Once an organization gets going with processes, the CIO often becomes what I call the chief process officer. The chief process officer is not the boss of the process owners. The chief process officer is sort of the organization' s chief of staff for process work, the center of expertise, the keeper of skills and methodology. And we see more and more organizations where the CIO takes on this additional role of chief process officer. If you're the chief process officer—the change agent within the company that's bringing about these process management improvements—where do you start?
HAMMER: The first thing to do is to assess your readiness as an organization to proceed. Do you have the leadership? Do you have the right culture in the organization? And if not, you have to start working on those gaps. What you need to do is identify your processes. If you don't know what they are, you're nowhere. You also need to do a major assessment of those processes in terms of some key issues: What's the status of the design of that process? Do you have one? Is it a good one or not? What about the metrics? Do you have end-to-end metrics or not? Do you have a process owner or not? Do the people who work in the process understand it? Does your infrastructure, which includes your IT systems, support the process? Based on that audit, you've identified what issues you need to work on. And so you say, "OK, I'm pretty good in process owner, not good in process metrics. Let me work on process metrics."
Sunday, November 18, 2007
As CIO Role Evolves, IT's Never Easy
Every now and then you hear something different, something coming from a different perspective and a different vantage point. That's when it's time to sit up and pay attention. Recently, two of the most respected individuals in their fields made the following observations: "I think you'll see a much higher degree of technical focus in the CIO and a higher understanding of technology in business across the C suite. The distinction that we're all so comfortable with -- that there's technology and there's business -- that distinction is going to vanish." That's Google CIO Douglas Merrill. "The role of the CIO is at a crossroads. CIOs can once again reinvent themselves -- and enhance their standing, influence and contribution to the corporation -- or their role will be marginalized: setters of technology standards, managers of infrastructure. ..or worse, overseers of a technically savvy procurement shop." That's IBM CEO Sam Palmisano. When I first read these statements, I immediately wanted to check my calendar because I thought I had gone back in time and was listening to Nicholas ("Does IT Matter?") Carr. Then I started thinking about why these two accomplished men were choosing this particular time to question the CIO's future when to me it seemed that the CIO role had regained whatever creditability it may have lost and has today more than earned its front row seat in the C suite. One reason I came up with is that the rapid adoption of consumer IT in the enterprise is causing the computing platform to shift under the CIO's feet, pushing him to once again immerse himself in technology and perhaps distracting him from the business of being strategic and driving innovation. A year ago it was rare that CIOs would mention mash-ups, RSS, blogs or wikis, Ajax and APIs as topics and technologies they were focused on. Now it's common. As Merrill says, "It's very difficult for classic CIOs to understand how to respond in the best way to this consumerization of IT. The nature of risk management is changing from clean cost-flow across technology to clean talent-flow into technology, which is a very different thing to manage." And a new challenge for CIOs. It is this challenge and opportunity that CIOs will need to address in the coming year to ensure that they don't, as Palmisano warns, get marginalized. Is the CIO once again at a crossroads? I would enjoy hearing your thoughts.
Michael Friedenberg is CEO and president of CXO Media. He can be reached at mfriedenberg@ cio.com
Michael Friedenberg is CEO and president of CXO Media. He can be reached at mfriedenberg@ cio.com
How to Create a Clear Project Plan
One of the critical factors for project success is having a well-developed project plan Here is a six-step approach to creating a project plan. It not only provides a road map for project managers to follow, but also acts as the project manager's premier communications and control tool throughout the project.
Step 1: Explain the project plan to key stakeholders and discuss its key components. Unfortunately, the "project plan" is one of the most misunderstood terms in project management. Hardly a fixed object, the project plan is a set of living documents that can be expected to change over the life of the project. Like a road map, it provides the direction for the project. And like the traveller, the project manager needs to set the course for the project, which in project management terms means creating the project plan. Just as a driver may encounter road construction or new routes to the final destination, the project manager may need to correct the project course as well. A common misconception is that the plan equates to the project time line, which is only one of the components of the plan. The project plan is the major work product from the entire planning process, so it contains all the planning documents. For example, a project plan for constructing a new office building needs to include not only the specifications for the building, the budget and the schedule, but also the risks, quality metrics, environmental impact, and so on. Components of the project plan include: Baselines: These are sometimes called performance measures because the performance of the entire project is measured against them. They are the project's three approved starting points for scope, schedule and cost. These provide the stakes in the ground, and are used to determine whether or not the project is on track during execution. Baseline management plans: These include documentation on how variances will be handled throughout the project. Other work products from the planning process: These include plans for risk management, quality, procurement, staffing and communications.
Step 2: Define roles and responsibilities. Identifying stakeholders - those who have a vested interest in either the project or the project outcome - is challenging and especially difficult on large, risky, high-impact projects. There are likely to be conflicting agendas and requirements among stakeholders, as well as different slants on who needs to be included. For example, the stakeholder list of the city council where a new office building is being constructed could differ from that of an engineering consulting firm. It would certainly include the developer who wants to build the office complex, the engineering firm that will build the office building, citizens who would prefer a city park, consultants to study the environmental impacts, the city council itself, and so on. The engineering firm may have a more limited view. It is important for the project manager to get clarity and agreement on what work needs to be done by whom, as well as which decisions each stakeholder will make.
Step 3: Develop a scope statement. The scope statement is arguably the most important document in the project plan. It is used to get common agreement among the stakeholders about the project definition. It is the basis for getting the buy-in and agreement from the sponsor and other stakeholders and decreases the chances of miscommunication. This document will most likely grow and change with the life of the project. The scope statement should include: Business need and business problem Project objectives, stating what will occur within the project to solve the business problem Benefits of completing the project, as well as the project justification Project scope, stated as which deliverables will be included and excluded from the project Key milestones, the approach and other components as dictated by the size and nature of the project. It can be treated like a contract between the project manager and sponsor, one that can only be changed with sponsor approval.
Step 4: Develop the project baselines. Scope baseline. Once the deliverables are confirmed in the scope statement, they need to be developed into a work breakdown structure (WBS) of all the deliverables in the project. The scope baseline includes all the deliverables produced on the project, and therefore identifies all the work to be done. These deliverables should be inclusive. Building an office building, for example, would include a variety of deliverables related to the building itself, as well as such things as impact studies, recommendations, landscaping plans, and so on. Schedule and cost baselines. 1. Identify activities and tasks needed to produce each of the deliverables identified in the scope baseline. How detailed the task list needs to be depends on many factors, including the experience of the team, project risk and uncertainties, ambiguity of specifications, amount of buy-in expected, etc. 2. Identify resources for each task, if known. 3. Estimate how many hours it will take to complete each task. 4. Estimate cost of each task, using an average hourly rate for each resource. 5. Consider resource constraints, or how much time each resource can realistically devote to this one project. 6. Determine which tasks are dependent on other tasks, and develop critical path. 7. Develop schedule, which puts all tasks and estimates in a calendar. It shows by chosen time period (week, month, quarter or year) which resource is doing which tasks, how much time each task is expected to take, and when each task is scheduled to begin and end. 8. Develop the cost baseline, which is a time-phased budget, or cost by time period. This process is not a one-time effort. Throughout the project, you will most likely be adding to and repeating some or all of these steps.
Step 5: Create baseline management plans. Once the scope, schedule and cost baselines have been established, create the steps the team will take to manage variances to these plans. All these management plans usually include a review and approval process for modifying the baselines. Different approval levels are usually needed for different types of changes. Not all new requests will result in changes to the scope, schedule or budget, but a process is needed to study all new requests to determine their impact to the project.
Step 6: Communicate!One important aspect of the project plan is the communications plan. This document states such things as: Who on the project wants which reports, how often, in what format and using what media How issues will be escalated and when Where project information will be stored and who can access it What new risks have surfaced and what the risk response will include What metrics will be used to ensure a quality product is built What reserves have been used for which uncertainties. Once the project plan is complete, it is important that its contents be delivered to key stakeholders. This communication should include such things as: Review and approval of the project plan Process for changing the contents of the plan Next steps - executing and controlling the project plan and key stakeholder roles/responsibilit ies in the upcoming phases.Destination SuccessDeveloping a clear project plan takes time. The project manager will probably be tempted to skip the planning and jump straight into execution. However, the traveller who plans the route before beginning a journey ultimately reaches the intended destination more quickly and more easily than the disorganized traveller who gets lost along the way. Similarly, the project manager who takes time to create a clear project plan will follow a more direct route toward project success.
Step 1: Explain the project plan to key stakeholders and discuss its key components. Unfortunately, the "project plan" is one of the most misunderstood terms in project management. Hardly a fixed object, the project plan is a set of living documents that can be expected to change over the life of the project. Like a road map, it provides the direction for the project. And like the traveller, the project manager needs to set the course for the project, which in project management terms means creating the project plan. Just as a driver may encounter road construction or new routes to the final destination, the project manager may need to correct the project course as well. A common misconception is that the plan equates to the project time line, which is only one of the components of the plan. The project plan is the major work product from the entire planning process, so it contains all the planning documents. For example, a project plan for constructing a new office building needs to include not only the specifications for the building, the budget and the schedule, but also the risks, quality metrics, environmental impact, and so on. Components of the project plan include: Baselines: These are sometimes called performance measures because the performance of the entire project is measured against them. They are the project's three approved starting points for scope, schedule and cost. These provide the stakes in the ground, and are used to determine whether or not the project is on track during execution. Baseline management plans: These include documentation on how variances will be handled throughout the project. Other work products from the planning process: These include plans for risk management, quality, procurement, staffing and communications.
Step 2: Define roles and responsibilities. Identifying stakeholders - those who have a vested interest in either the project or the project outcome - is challenging and especially difficult on large, risky, high-impact projects. There are likely to be conflicting agendas and requirements among stakeholders, as well as different slants on who needs to be included. For example, the stakeholder list of the city council where a new office building is being constructed could differ from that of an engineering consulting firm. It would certainly include the developer who wants to build the office complex, the engineering firm that will build the office building, citizens who would prefer a city park, consultants to study the environmental impacts, the city council itself, and so on. The engineering firm may have a more limited view. It is important for the project manager to get clarity and agreement on what work needs to be done by whom, as well as which decisions each stakeholder will make.
Step 3: Develop a scope statement. The scope statement is arguably the most important document in the project plan. It is used to get common agreement among the stakeholders about the project definition. It is the basis for getting the buy-in and agreement from the sponsor and other stakeholders and decreases the chances of miscommunication. This document will most likely grow and change with the life of the project. The scope statement should include: Business need and business problem Project objectives, stating what will occur within the project to solve the business problem Benefits of completing the project, as well as the project justification Project scope, stated as which deliverables will be included and excluded from the project Key milestones, the approach and other components as dictated by the size and nature of the project. It can be treated like a contract between the project manager and sponsor, one that can only be changed with sponsor approval.
Step 4: Develop the project baselines. Scope baseline. Once the deliverables are confirmed in the scope statement, they need to be developed into a work breakdown structure (WBS) of all the deliverables in the project. The scope baseline includes all the deliverables produced on the project, and therefore identifies all the work to be done. These deliverables should be inclusive. Building an office building, for example, would include a variety of deliverables related to the building itself, as well as such things as impact studies, recommendations, landscaping plans, and so on. Schedule and cost baselines. 1. Identify activities and tasks needed to produce each of the deliverables identified in the scope baseline. How detailed the task list needs to be depends on many factors, including the experience of the team, project risk and uncertainties, ambiguity of specifications, amount of buy-in expected, etc. 2. Identify resources for each task, if known. 3. Estimate how many hours it will take to complete each task. 4. Estimate cost of each task, using an average hourly rate for each resource. 5. Consider resource constraints, or how much time each resource can realistically devote to this one project. 6. Determine which tasks are dependent on other tasks, and develop critical path. 7. Develop schedule, which puts all tasks and estimates in a calendar. It shows by chosen time period (week, month, quarter or year) which resource is doing which tasks, how much time each task is expected to take, and when each task is scheduled to begin and end. 8. Develop the cost baseline, which is a time-phased budget, or cost by time period. This process is not a one-time effort. Throughout the project, you will most likely be adding to and repeating some or all of these steps.
Step 5: Create baseline management plans. Once the scope, schedule and cost baselines have been established, create the steps the team will take to manage variances to these plans. All these management plans usually include a review and approval process for modifying the baselines. Different approval levels are usually needed for different types of changes. Not all new requests will result in changes to the scope, schedule or budget, but a process is needed to study all new requests to determine their impact to the project.
Step 6: Communicate!One important aspect of the project plan is the communications plan. This document states such things as: Who on the project wants which reports, how often, in what format and using what media How issues will be escalated and when Where project information will be stored and who can access it What new risks have surfaced and what the risk response will include What metrics will be used to ensure a quality product is built What reserves have been used for which uncertainties. Once the project plan is complete, it is important that its contents be delivered to key stakeholders. This communication should include such things as: Review and approval of the project plan Process for changing the contents of the plan Next steps - executing and controlling the project plan and key stakeholder roles/responsibilit ies in the upcoming phases.Destination SuccessDeveloping a clear project plan takes time. The project manager will probably be tempted to skip the planning and jump straight into execution. However, the traveller who plans the route before beginning a journey ultimately reaches the intended destination more quickly and more easily than the disorganized traveller who gets lost along the way. Similarly, the project manager who takes time to create a clear project plan will follow a more direct route toward project success.
Subscribe to:
Posts (Atom)