Managing the Cost of IT Risk in the Enterprise

Spending for IT inevitably includes the cost of risk. A common problem for enterprise IT management is how to estimate and budget for the cost of risk, how to avoid or mitigate these costs when possible, and how to provide guidance to the people who plan, budget, and manage IT investments.

Financial horror stories are widely publicized, particularly in the public sector where IT budgets and spending are more accessible to the media. Most of us have read about major systems that overrun estimates by millions of dollars, fail to meet business requirements, or become very expensive to operate and maintain.

However, estimates are just that, and actual costs, schedules, and outcomes may vary. The cost of risk may encompass cost overruns, the financial impact of schedule delays, diminished performance of the delivered system, unexpected training or support costs, or failure to achieve financial benefits—to name a few.

The Problem

The cost of risk is poorly understood at the enterprise level in many organizations, and underlying reasons for this vulnerability often encompass the following:

1. Cost estimates and risk assessments are often performed on a piecemeal basis at the individual project level, rather than the overall investment level
2. Most major IT investments actually involve multiple projects throughout the system lifecycle, and inadequate attention is given to a holistic review of costs and risks at the planning, development, deployment, and maintenance steps
3. The corporate Knowledge Base is fragmented, meaning that investment managers may not have access to past experience with the cost of risk within the enterprise
4. Inadequate attention to establishing, validating, and managing the Performance Measurement Baseline at the beginning of projects greatly increases the risk of unexpected costs
5. The enterprise has insufficient standards, guidance, and governance for estimating, tracking, and controlling the cost of risk.

Another problem is that the cost of risk is an unpopular item in budget reviews. If an investment estimates an overall cost of risk of 14 percent, for example, there could be push back from budget reviewers. “Can’t you manage better so there is less risk to the budget?” they may say. In such an environment, investment planners will be tempted to cover up the cost of risk by using various fudge factors and reducing the publicized risk to more palatable levels.

However, the problem with covering up some of the risks is that the enterprise never really knows the true cost of risk. Failure to identify and acknowledge risks is actually an unacceptably expensive game:

• If you don’t identify and acknowledge all risk costs, you can’t develop enterprise policies and processes that might avoid or mitigate them
• Understated risk costs are misleading for planning and budgeting future investments—so that the enterprise remains locked into a continuing cycle of unexpected overruns.

Published Earned Value Management (EVM) data, such as that appearing in the OMB IT Dashboard, is at a high level. While these data provide useful overall performance indicators, they seldom pinpoint the detailed risk issues. If the EVM data are truly maintained according to the 32 criteria of the 748-B standards, a much better understanding can be obtained by drilling down into the details, reviewing the Corrective Action Plans, and analyzing the changes to the Performance Measurement Baseline (and/or re-baseline requests).

There may also be situations where reliable corporate experience isn’t available to a new investment (such as a huge system or new areas of cloud or mobile computing). In these cases, it may be necessary to have a policy of developing external case studies to document the experience of outside organizations that have implemented investments of similar scope and functionality. As we have stated in our newsletter articles, it is best to get the data from a host organization rather than a vendor. Even highly-respected vendors are trying to make a sale, offer optimistic estimates, minimize risk, and may not be aware of all costs or risks which are experienced by a host organization.

In addition to specific investment risks, the enterprise should also consider the impact of risks on the organization as a whole, its mission, and its strategic plan. Failure to support the core mission or accomplish strategic objectives can be a disaster.

The Solution

The Quick Task solution seeks to achieve the following:

• Increase consistency in estimating, budgeting, and reporting the cost of risk throughout the enterprise
• Strengthen the focus on risk assessment and management at the IT investment level (program or multi-project system level) in addition to project-level risk
• Improve the corporate Knowledge Base about the cost of risk
• Identify risk patterns in the enterprise that may be avoided or mitigated—to reduce the cost of risk
• Strengthen enterprise-wide policies and processes for estimating, reporting, and overseeing IT investment risks.

The task will require involvement of IT leadership, key personnel responsible for risk and performance metrics, and representatives of program and project management. Information will be needed about policies, practices, performance data, and supporting documents. The task will include detailed analysis and discussions. The output will be a Plan of Action for Enterprise-Wide IT Investment Risk Management.

What’s New

For Federal agencies, there is sharply increased scrutiny of IT budgets. Strengthened enterprise-wide oversight of investment risks is essential for maintaining credibility with OMB, GAO, and Congress.

QT Plan

This task will require 3 – 4 months, depending on the availability of information and the schedule of the Leadership Team. Milestones are as follows:

1. Entry meeting to discuss task and scope, and to collect background documents
2. Draft the Quick Task management plan
3. Form the Leadership Team for the task and review draft Quick Task plan
4. Finalize Quick Task task plan
5. Review the current enterprise-level policies, processes, and knowledge bases for overseeing and documenting the cost of risk
6. Identify a representative cross-section of major investments to review in detail, and:

6.1. Review current risk assessment and cost estimating practices at the project and investment levels

6.2. Drill down into risks encountered by representative investments

6.3 Conduct group interviews with selected investment managers and PMs

7. Analyze and categorize investment risks, seeking opportunities to avoid or mitigate risks
8. Present findings to the task Leadership Team
9. Conduct additional fact-finding
10. Develop a draft Plan of Action for Enterprise-Wide IT Investment Risk Management, covering:

10.1. Enterprise policies, processes, and governance

10.2. Guidance for documenting and reporting cost estimates, cost of risk, Performance Measurement Baseline, Earned Value Management, risk management, and re-baselining

10.3. Enterprise Knowledge Base for project, program, and investment risks and cost of risks

10.4. Opportunities for cost cutting through avoidance or mitigation of investment risks

10.5. Other actions

11. Conduct workshop for task Leadership Team to refine the plan of action
12. Finalize the Plan of Action for Enterprise-Wide IT Investment Risk Management
13. Conduct a Closeout Briefing for all participants and outline follow-up steps (including assignment of roles and responsibilities).

Reference

GAO Cost Estimating and Assessment Guide, Best Practices for Developing and Managing
Capital Program Costs. See especially Chapters 13 Sensitivity Analysis and 14 Risk Cost and Uncertainty. Government Accountability Office, GAO-09-3SP, March 20009.

2008 NASA Cost Estimating Handbook; see especially Volume 2 Cost Risk.

See PMBOK Guide(© 2013 Project Management Institute), Fifth Edition:  11. Project Risk Management.

See The Standard for Program Management (© 2013 Project Management Institute), Third Edition: 8.7 Program Risk Management.

See The Standard for Portfolio Management (© 2013 Project Management Institute), Third Edition: 8. Portfolio Management.

Using Risk-Adjusted Costs for Projects, P2C2 Group, Inc.

Smarter Enterprise Management with Earned Value Management, P2C2 Group, Inc.

Managing the Project Risks of Federal Initiatives, P2C2 Group, Inc.

Financial Models for IT Investments, White Paper, P2C2 Group, Inc.

Make Better Decisions Using Case Studies, P2C2 Group, Inc.

Seven Steps to Smarter CPIC, P2C2 Group, Inc.

Enterprise-Wide Corporate Knowledge Base for IT, QT Blog, Jim Kendrick.


More Help

Jim Kendrick and the P2C2 Group, Inc. provide management consulting and Subject Matter Expert services in this Quick Task area: kendrick@p2c2group.com.

Last Word

The objective of portfolio risk management is to accept the right amount of risk commensurate with the anticipated reward to deliver the optimum outcomes for the organization in the short, medium, and longer term.
–PMI, The Standard for Portfolio Management.

Managing Your Portfolio of PMOs

                                                

A large enterprise often has dozens of IT PMOs. These substantial investments need to be recognized and managed as a PMO portfolio.

PMOs have become commonplace and are often known as Portfolio Management Offices, Program Management Offices, and Project Management Offices. They should boost project and investment performance and reduce risk, right?  Maybe; it depends. PMI’s Pulse of the Profession™ reported that, while PMOs are increasing, there was evidence that having a PMO does little to improve project success rates. This finding was communicated in PMI Community Post, February 25, 2013, and the article further stated “It is not surprising, therefore, that many PMOs have a short ‘shelflife.’”

Many additional reasons for short “shelflife” are suggested in a global, multi-year study reported by Hobbs and Aubry (see Reference section). For example, they write “The PMO is an organizational innovation that is a recent and important phenomenon. But if it is an innovation, it is unstable and still evolving.” (Page 162)  They further state:

Tension emerges naturally on the issue of control of projects. In some organizations a distinction is introduced between monitoring and controlling. Many PMOs monitor project progress and performance. Some are limited to the monitoring function, while others have a role to play in controlling projects. Tensions emerge when PMOs exert control over projects for which they do not have primary responsibility. In some situations, PMOs are allowed to report information on projects, to ask questions, to integrate information by portfolio, but are not allowed to make judgments and even less to dictate actions on projects. This leads to a paradox where a PMO cannot take action but at the same time can be criticized for its inability to affect project performance.  (Page 156)

In its introduction to the book by Hobbs and Aubry, the Project Management Institute states “…, the authors address the roles that PMOs play in organizations, which provides valuable insights for better creating, structuring and governing PMOs. When designing a PMO, an organization has a variety of choices regarding the PMO’s structure and role assignment. By providing a way to define PMOs by type, this research explores how to set up and define a PMO, depending upon the specific type of PMO The authors discuss the many bases for the types of PMOs, including structural characteristics and functions, and how these types affect the PMO’s role in the organization.”

The variety of purposes and roles of PMOs can lead to confusion and misunderstanding at the enterprise level. As Prasad Kamath is quoted as saying in the PMI Community Post cited above,

“One thing that I have seen missing is a sound understanding of what exactly a PMO is,” he says. He has rarely seen a charter for a PMO signed off by executive management.

The Problem

The PMO can be one of the most incorrectly managed and underutilized portions of an organization, according to ProjectSmart.. Findings presented at the 2010 Gartner ITxpo indicate that nearly half of all PMOs result in failure. The question, then, is why do such a drastic number of businesses feel that their PMOs do not deliver value?

The P2C2 Group’s viewpoint is that PMOs need enterprise-level leadership and oversight. We are not suggesting that all PMOs in an organization must be alike, or have the same functions, or the same structure. However, there is value in making conscious decisions about each PMO’s role, its charter, its estimated lifespan, and how it supports the overall enterprise IT management strategy.

PMOs can be expensive, both in terms of personnel assigned to them and the amount of work required by others to respond to PMO monitoring and reporting requirements. If the enterprise treats each PMO as a project—an investment—it can be evaluated in rational terms: objectives, scope, costs, benefits, risks, executive sponsorship, plans, execution, and control. Each can also be evaluated in terms of value to the organization and stakeholders.

In such a context, an enterprise has a portfolio of PMOs. It is incumbent upon enterprise IT leadership to manage this portfolio on a continuing basis. Since some PMOs are embedded in programs or large projects, it may be necessary to take a matrix management approach, where such a PMO is reviewed both in the PMO portfolio and as part of the portfolio in which it is embedded.

Given that PMOs are generally “projects” with a defined timeframe or duration, it is important to view the completion and termination of a PMO project as normal—and not necessarily an indicator of failure. Moreover, individual PMOs may evolve and encompass changes in roles or workloads. These changes should be treated like other projects, with transparent management decisions authorizing modification of the performance measurement baseline.

The Solution

Enterprise IT leaders should organize a portfolio of its PMOs and develop policies and processes for their authorization, establishment, oversight, performance review, enhancement, and (when appropriate) closeout and termination. The portfolio management framework should be flexible enough to encompass PMOs with varied roles and timeframes.

We recommend the following overarching principals for managing PMOs:

-       Oversee all PMO investments at the enterprise level as a portfolio
-       Identify, assess, and monitor PMO and PMO-like functions within the overall enterprise
-       Increase the visibility of the PMO portfolio in the governance process
-       Treat each PMO investment as a project
-       Harmonize enterprise policies and practices with PMO operations
-       Support, develop, and promote a vibrant PMO culture including use of best practices
-       Make decisions about PMO investments as part of the capital investment process—initiate those needed to support priorities, modify those that need to be strengthened, consolidate those which overlap, and terminate those that are underperforming or no longer needed.

In general, the development of strong, successful PMOs throughout the enterprise will be an evolutionary process. In recognition of this, we have broken down our action steps into three limited-duration Quick Tasks:

#1, Roadmap for Enterprise-Level PMO Portfolio Management. The purpose of this step is to define a plan of action for an enterprise-level PMO oversight, governance, policy and process. It requires involvement of enterprise leadership and formulation of an action plan (roadmap). The roadmap becomes the core of a charter for developing and implementing enterprise-level PMO management.

#2, Enterprise-Wide PMO Identification and Review. This step inventories and analyzes the characteristics of existing (and any planned) PMOs in detail. It collects detailed input from stakeholders, PMO directors, and others. It categorizes each PMO by roles and identifies strengths, benefits, and issues. Best practices and lessons learned are identified. A comparison is made to PMO processes and current enterprise policies and processes. There will be an assessment of the feasibility of establishing an enterprise PMO portfolio. The output will be a summary report with findings and recommendations.

#3. Enterprise-Wide Strategic Plan for the PMO Portfolio.  This step builds on detailed information available regarding PMOs in the enterprise, as developed in the previous step. The objective will be to develop a comprehensive strategy for the governance, policy, and processes applicable to PMOs in the enterprise. The task should be guided by a leadership team with opportunities to review and interact regarding findings. Output will be a strategic plan for enterprise oversight of PMOs, including an implementation plan.

There are many relate considerations. For example, communications and change management will be important. Establishing an enterprise-wide PMO community may help. It could be helpful to explore options for a Wiki, workshops, and facilitated reviews along the evolutionary path.

What’s New

IT is changing rapidly. Keeping PMOs aligned with these changes can be challenging. Cloud computing, mobile computing, and social media are all having an impact, as is a trend toward system consolidation. Like any other major cluster of investments, the PMO portfolio should be managed on an ongoing basis.

QT Plan

The Quick Plan needs to be tailored to each enterprise’s situation and the general characteristics of its PMOs. The P2C2 Group’s approach would be to tailor the plan of action following additional discussion. We have segmented the work into three Quick Tasks, to illustrate our general approach.

QT #1, Roadmap for Enterprise-Level PMO Portfolio Management. The purpose of this task is to define a plan of action for an enterprise-level PMO oversight and governance policy and process. Duration would be approximately 6 weeks, resulting in a roadmap, scope, and schedule for follow-up action.

-       Organization of an enterprise leadership team for the task
-       Summarization of available information about PMOs in the organization
-       A workshop to discuss needs and opportunities, group meetings with stakeholders
-       Summary of findings
-       Draft roadmap and action plan
-       Detailed meeting of leadership team to make decisions
-       A Roadmap (Plan-of Acton Report)
-       A project charter for enterprise-level PMO management.

QT #2, Enterprise-Wide PMO Identification and Review. This task is an in-depth review of the review items discussed above. Task duration would be about three months, and the objective would be to establish an accurate snapshot of PMOs in the enterprise including related problems and opportunities. The task should be guided by a leadership team with opportunities to review and interact regarding findings. Output would be a report that addresses the following information:

-       Brief the enterprise leadership team about the task
-       Identify all PMOs and PMO-like units in the enterprise
-       Document the roles, cost, and timeframe of each
-       Review current enterprise-wide accountability requirements for PMOs
-       Discuss expectations of executive/business sponsors of each PMO
-       Review problems and successes with a cross-section of PMO directors and programs/projects reporting to PMOs
-       Assess how current organizational policy and processes impact PMOs
-       On a preliminary basis, categorize PMOs by role/function or other key attributes and identify the most salient benefits
-       Look at lessons learned and identify any potential “best practices”
-       Assess the feasibility of establishing an Enterprise PMO Portfolio
-       Prepare a draft report of findings and recommendations
-       Present the findings to the enterprise leadership team
-       Prepare a final report of findings and recommendations

QT #3. Enterprise-Wide Strategic Plan for the PMO Portfolio.  This task builds on detailed information available regarding PMOs in the enterprise. Task duration would be three to four months, and the objective will be to develop a comprehensive strategy for the governance, policy, and processes applicable to PMOs in the enterprise. The task should be guided by a leadership team with opportunities to review and interact regarding findings. Output would be a strategic plan for enterprise oversight of PMOs, including an implementation. Preparation of the plan should consider questions such as:

-       How does the plan—and PMOs—support the overall IT strategic plan?
-       What is the strategy for enhancing the value and likelihood of success for the portfolio of PMOs?
-       Who will provide enterprise-level governance for the portfolio?
-       Should PMOs be considered projects and follow project management protocols?
-       Should a PMO charter be required, and should it have approval at the enterprise level?
-       Are PMO investments aligned with enterprise IT strategy and priorities?

o    Could some PMOs be consolidated?

o    Are there urgent priorities that need a PMO?

o    Should some PMOs be terminated?

-       How will PMOs embedded in other investments be treated?
-       Should all or most PMOs support a core of enterprise-level metrics?
-       By what criteria will PMOs be reviewed for cost, benefits, and intended results?
-       How will the enterprise support PMOs with training, career development, and collaboration about best practices?


Reference

PMI Community Post, PMO Survival – Can Charters Help?  February 25, 2013.

Discussion of the 2011 CHAOS Study and Project Management Software, in a Girl’s Guide to Project Management (blog),

The Project Management Office (PMO): A Quest for Understanding.  Brian Hobbs, PhD, MBA, PMP; and Monique Aubry, PhD, MPM.  © 2010, Project Management Institute.  ISBN” 978-1-933890-97-5. Book available for purchase. PMI members can get link to download for free at  http://www.pmi.org/Knowledge-Center/Research-Completed-Research/The-Project-Management-Office-PMO-A-Quest-for-Understanding.aspx.

Project Smart, a U.K. perspective on PMOs.

Top 10 PMO Worst Practices: Pitfalls to Avoid. Daptive White Paper.

The Standard for Portfolio Management, Third Edition. 2013, Project Management Institute.  ISBN: 978-1-935589-69-3.  See 1.9 Role of the PMO for Portfolio Management.

Measures and Metrics for PMO Success, Jim Kendrick, P2C2 Group. Project Management Office Summit.


More Help

Jim Kendrick and the P2C2 Group, Inc. provide Facilitator/Coach and Subject Matter Expert services in this Quick Task area: kendrick@p2c2group.com.

Last Word

The study “confirms that the PMO is deeply embedded in its host organization, and the two coevolve.” Hobbs and Aubry, in reference cited, page 162.

Enterprise-Wide Action Plan for Agile IT Management

Agile management has become a catch phrase for many CIOs and enterprise information technology shops. Yet, like all catch phrases, the devil is in the details. While there are efforts to unify agile methods, the approaches and emphases can be quite varied—particularly as applied by individual program and project managers.

The history of agile methodology, including the many inputs that contributed to “agile,” is summarized in a paper by David F. Rico, The History, Evolution and Emergence of Agile PM Frameworks. You can also find a broad statement of Principles behind the Agile Manifesto and the Agile Manifesto, originally focused on software development.

Agile is discussed widely among Federal IT leadership. The Government Accountability Office (GAO) released a report on effective practices and government challenges in applying agile. Margie Graves, Deputy CIO at DHS recently proposed “agile first” at the Federal Mobile Computing Summit, where she spoke. According to Federal Computer Week, Graves said agile could often save time and money, while pointing out that some processes such as testing and security need to be done differently.

At its best, agile is a means for coping with uncertainty—using quick iterations and collaborative interactions to discover innovation and cost-efficient solutions.  At its worst, agile could simply be an excuse for flying by the seat of one’s pants without clear plans or use of obtainable information.

Agile IT system development is typically contrasted with traditional Waterfall development methods. The old editions of the Project Management Book of Knowledge (PMBOK™) and many System Life Cycle manuals were grounded in a linear, Waterfall-style methodology: initiate based on the problem, plan in detail, execute the plan, control according to the plan, and declare success (project close). In the Federal government, many of the management controls for IT are grounded in Waterfall assumptions.

The problem with the Waterfall method is that many development projects start out with a great deal of uncertainty, and the system life cycle pathway tends to be long, tedious, and expensive. After many months or even years of development, the results can be disappointing.

The Problem

Agile management is becoming an essential discipline and process for many situations in information technology, particularly in today’s SOA, cloud, and mobile app environment. However, IT leadership at the enterprise level should examine policy, governance, and performance management processes to determine how to incorporate agile successfully. Following are examples of issues to be considered.

“Agile” means different things to different people, and enterprise IT governance falls into shambles if dozens of program and project managers are disconnected from performance accountability, oversight, and documented repeatable processes.

A large IT organization needs to define agile and integrate the processes into its governance and investment management structure. It is also important to evaluate the environment necessary for agile to be successful. Many agile teams negotiate their working relationships among themselves, rather than following canned job descriptions. Face-to-face communications and frequent interactions are also important, though conferencing and messaging technology is extending its reach to agile distributed teams who work at multiple locations. In addition, documenting an agile project frequently requires new tools—because details of the solution may change every several weeks, or even more frequently.

Another issue is determining who is qualified to lead and manage an agile initiative. Some of the pioneers of agile methods argue strongly against certification programs; yet a variety of credentials have appeared. The Project Management Institute now offers the PMI-Agile Certified Practitioner (PMI-ACP) credential. Other significant credentials include Certified Scrum Professional (CSP) and Certified Scrum Master (CSM). Joseph Flahiff makes a comparison of the three credentials is at Project Management Institute’s Whitewater Projects.

A fundamental issue is when to use agile rather than traditional system development methods. In many cases, agile is better suited to IT investments that:

• Are smaller
• Have near-term completion dates
• Need iterative feedback from prospective IT users
• Are characterized by uncertainty, the opportunity for innovation, or a need for flexibility
• Require exploration of a series of near-term alternatives
• Or makes sense for some of the segments of a large traditional IT investment.

Agile tends to work best for quick runs and is usually focused on shorter term project objectives. Conversely, traditional program and system development approaches may be necessary for pursuing long-term objectives and the enterprise-level IT strategic plan.

The Solution

If you haven’t done so already, your enterprise should consider updating its guidance, decision processes, documentation requirements, and investment management standards to harmonize with policy that incorporates agile into the overall framework. There is no “one size fits all solution,” and we do recommend that you carefully consider developing a plan that fits the characteristics of your organization.

Further, we recommend that you apply an agile Quick Task for integrating your enterprise IT management policy and practices with agile. An early activity should be to review the agile initiatives that are underway or completed within your organization. Explore:

• What worked well and what didn’t?
• Are some agile implementations more successful than others?
• Were there policy or process barriers that need to be resolved?
• What kinds of qualifications and training were associated with successful outcomes?
• Has certification been valuable for selecting agile project managers?
• What were the benefits of agile, both quantitative and qualitative?
• Did agile save time or money?
• What have been the risks encountered or avoided by using agile?
• What were the decision criteria for selecting agile methods?
• Do participants in the current or recent agile initiatives have suggestions or lessons learned?
• Who are the stakeholders who need to be involved in agile? Do they need orientation or training?
• How did agile projects handle enterprise documentation standards, performance reporting, and life cycle gate reviews?

It is plausible that your organization could embrace several approaches to agile management, but there should be overarching policies, performance reporting, review checkpoints, and assessments at the enterprise portfolio management level.

What’s New

• Cloud computing offers a number of opportunities for agile management
• Mobile apps are opening software development to quick, focused solutions
• The trend toward system consolidation may offer opportunities
• The focus on short-term useable segments of major systems may speed up or reduce the costs of initial prototyping, provided that the solutions are scalable to enterprise-wide requirements.

QT Plan

The purpose of this Quick Task is to prepare a phased action plan for incorporating agile management into the guidance, governance, and processes for enterprise IT management in a specific large organization environment. The estimated period of performance for the task is four months, and task elements are as follows:

1. Develop a Task Plan
2. Organize a Task Leadership Team to oversee the necessary reviews and change management
3. Identify agile projects in your enterprise—both completed ones and those underway
4. Classify agile projects in your organization, using categories such as core system development, infrastructure, cloud computing, mobile computing, etc.
5. Rank order the projects on the basis of key performance factors such as cost, schedule, technical outcomes, and user satisfaction
6. Seek agile characteristics that distinguish high-performing from low-performing investments, such as leadership characteristics, leader qualifications, agile processes, training, team characteristics, stakeholder involvement, and interactions with IT governance policy and processes
7. Conduct several focus groups with agile management participants and distil recommendations from their perspective regarding how your organization can optimize successful use of agile methods
8. Interview top-level executives regarding their expectations for agile
9. Develop a prototype of recommended agile policy and processes that are appropriate to your organization
10. Assess how existing enterprise IT policy, governance, and management processes will need to be updated to use agile optimally in your organization
11. Draft an Agile Plan of Action
12. Seek input from functional managers: budget, IT architecture, acquisition, CPIC, operational management, portfolio management, etc.
13. Conduct a workshop with enterprise leaders and managers to refine the Agile Plan of Action
14. Finalize the Plan of Action
15. Conduct a Closeout Briefing for all participants and outline follow-up steps (including assignment of roles and responsibilities).

Reference

Software Development: Effective Practices and Federal Challenges in Applying Agile Methods. Government Accountability Office, GAO-12-681. 2012.

Agile Project Management: Creating Innovative Products (2nd Edition), Jim Highsmith. ISBN 10: 0-321-21977-5. 2009.

The Business Value of Agile Software Methods, Maximizing ROI with Just-in-Time Processes and Documentation. Dr. David F. Rico, PMP, CSM, Dr. Hasan H. Sayani, and Dr. Saya Sone, PMP. ISBN 978-1-60427-031-0. 2009.

Extreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility. Doug DeCarlo. ISBN 0-7879-7409-9. 2004.

Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin. ISBN 0-13-704329-5. 2012.

PMI Agile Certified Practitioner

Scrum.org

Scrum Alliance

More Help

Jim Kendrick and the P2C2 Group, Inc. provide executive facilitator, workshop leader, management consulting, and policy support in this Quick Task area: kendrick@p2c2group.com.

Last Word

We suggest that you view the incorporation of agile management as an evolutionary process. Agile should lead to repeatable successful methods that strengthen the performance of IT in your organization.