Tag: Planning

From the Sponsor’s Desk – Pulling the Project Plug

Written by Drew Davison on July 19, 2011. Posted in Articles. 7 Comments on From the Sponsor’s Desk – Pulling the Project Plug

In my last post, Building Project Management Maturity, we looked at a company that found itself at a competitive disadvantage because of their project management performance and the steps they took to improve their performance and capability and level the competitive playing field.

In this post, we’ll look at the value that a mid-project audit can provide by helping stakeholders confirm or rethink the motivations and rationale for an initiative. In this case, the audit helped avoid potentially costly enterprise wide conflicts through a change in corporate priorities.

The Situation

This Canadian based mining company had contracted with one of the “Big Four” accountancy firms to assess the organization’s readiness to implement the International Financial Reporting Standards (IFRS), determine the impact on their world-wide operations and recommend an appropriate plan of action.

While European public companies have been applying these standards since January 2005, in Canada, the Accounting Standards Board had proposed that Canadian GAAP for publicly accountable enterprises migrate to IFRS over a transition period. The move to IFRS would impact many areas of business including fundamental decision-making processes and would change the way companies presented their business results to analysts, investors and other stakeholders.

The Goal

The company planned to develop and implement IFRS compliant practices and procedures throughout its global operations in accordance with the targeted transition period.

The Project

The Finance organization launched the IFRS initiative and contracted with the accounting firm which assigned senior consultants who had extensive experience planning and implementing IFRS solutions in Europe. A working group was established to liaise with the consultants and included Finance department managers and staff with some consultation with the head office IT organization.

As the consultants were wrapping up their IFRS assessment, the head of the Internal Audit organization heard rumblings from the regions concerning the work being done, its complexity and the regions’ lack of involvement to that point. He proposed to the Finance VP that an audit be done to assess the performance of the project to date, identify gaps and target opportunities to provide the foundation for a successful implementation. His recommendation was approved.

Internal Audit launched the project audit using the Project Pre-Check’s Diagnostic process. The assessment started with the identification of key stakeholders from all global operations and involved interviews to solicit their views on progress to date and thoughts and suggestions on future plans.

The assessment process used a selected subset of Project Pre-Check’s Decision Areas (47 of the 125) covering the nature of the planned change, the environment within which the change would be implemented, organizational processes and practices that could be leveraged and the management of the project itself. The 47 Decision Areas were used to gauge three perspectives:

Stakeholder views from face to face and phone interviews, including stakeholders from the corporate office, from the regions and the consultants.
Review of deliverables from the project to date
Review of any project management methodologies, practices and templates used.

The interview results found that the IFRS project’s overall level of stakeholder agreement at this stage of the project was 2.4 on a scale from 1 to 5, based on the following definitions:

1 – Not addressed, don’t know or disagree with current decision

3 – Somewhat addressed

5 – Completely addressed

The interview results identified 7 of the 47 Decision Areas addressed in the assessment

(15%) as areas of divergence (at least one of the stakeholders was less than comfortable with how a best practice was applied). 40 Decision Areas (85%) where identified as gaps (where the majority of stakeholders expressed a lack of comfort). The results showed that these challenges needed to be addressed posthaste to avoid a less than successful outcome.

Key areas of concern were those areas relating to the scope of the project, organizational priorities, the target dates, stakeholders (confusion over the sponsor and project manager), decision making responsibilities and ongoing governance.

The audit took about six weeks to complete. The Audit leader presented the findings and recommendations to the Finance VP. The recommendations included:

Confirm the sponsor and project manager
Form a stakeholder group including stakeholders from all affected organizations
Establish the priority of the IFRS initiative relative to other competing projects
Work towards full agreement on all 47 Decision Areas included in the audit.

The Results

The project was deferred! After reviewing the audit results and conferring with stakeholders in head office and the regions, the Finance VP acknowledged that the IFRS project would face significant risks trying to go head to head against other initiatives that were judged to have higher corporate priority.

The audit helped bring the disparate views of the stakeholders to the surface and escalate the concerns about corporate priorities to the executives who had the information and authority to make the right call. Prompt action by the Audit head and a comprehensive six week review focusing on the key project stakeholders helped this company make a timely decision and avoid the financial and operational risks of too many projects chasing too few critical resources.

How a Great PM Could Have Helped

The IFRS project was at a disadvantage from the moment it was launched – it had no internal project manager. Sure, the consultants managed their piece of the work. But no one from the company was formally responsible for managing the changes to the company’s practices and operations from inception to successful delivery.

Had a Great PM been assigned, undoubtedly he or she would have addressed the following fundamentals:

1. Establish the project’s sponsor clearly and publicly. On the internal project documents and the report prepared by the consultants, three different sponsors were identified. That’s a recipe for chaos. Even co-sponsors can lead to muddled and circuitous decision-making. Pick one!

2. Identify and engage the other project stakeholders across the enterprise and around the globe and ensure that they understand their roles and responsibilities. All stakeholders – the sponsor, targets, change agents and champions – need to contribute according to their responsibilities on a multitude of fronts for the project to be successful.

3. Manage the level of stakeholder agreement on the relevant decision areas. Work to resolve the gaps and areas of divergence up front and on an ongoing basis as new issues and conflicts crop up. Early estimates of the cost of the IFRS project ran in the $8 million to $10 million range to be implemented over an 18 month period. That means navigating a mountain of mole hills. A Great PM would thrive on that challenge.

4. Managing stakeholder agreement on the relevant Decision Areas will help a Great PM ensure that critical questions about the planned change and the environment within which the change is being implemented are addressed. A Great PM will ensure that the impact on and/or use of appropriate company assets (methodologies, practices, resources, etc.) is fully articulated and endorsed by all. Finally, a Great PM will ensure the approach to planning organizing and controlling the project is fully supported by the other stakeholders and that project communications address their collective and individual needs.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a Great PM, and your sponsor’s best friend.

Next, we’ll look at the challenges a Great PM faced as he tried to guide the upgrade of extremely out of date but mission critical content management software through the demands of the business and the ineptitudes of two external contractors. In this case, the Great PM’s tough love approach won the day, and a successful project.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Anybody Can Manage a Project, Part 2

Written by Drew Davison on November 24, 2010. Posted in Articles. 7 Comments on From the Sponsor’s Desk – Anybody Can Manage a Project, Part 2

In my last post, Anybody Can Manage a Project, Part 1, I reviewed a failed project that had a PM with no prior PM experience, no formal PM education and no in-place mentor. I also looked at how a Great PM could have leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results.

In this post, we’ll look at a similar situation with a much more successful outcome. The PM was asked to manage an enterprise wide project with no prior PM experience, no formal PM education and no in-place mentor and she pulled it off. That’s why I call this post Anybody Can Manage a Project, Part 2!

The Situation

A global mining company had a number of Enterprise Resource Planning (ERP) solutions in place in various regions and departments as a result of their growth by acquisition. Work was in progress to standardize their ERP platforms. As part of that standardization effort, the organization also planned to implement a global standard for segregation of duties (SOD) to meet required compliance standards (i.e. Sarbanes-Oxley).

The Goal

The company planned to develop and implement a global SOD standard that would be used to support the management of controls for regional ERP applications and to support the management of SOD risks into the future. The project would also benefit other functions including compliance.

The Project

The Finance organization launched the SOD standards initiative and developed a comprehensive SOD matrix over a period of eight months. A Working Group was established to move the project forward and included Finance department managers and staff with some consultation with the head office IT organization.

As Finance was wrapping up their SOD design, the head of Global Internal Audit heard rumblings from the regions concerning the work being done, its complexity and the regions’ lack of involvement to that point. He proposed to the Finance VP that an audit be done to assess the performance of the project to date, identify gaps and target opportunities to provide the foundation for a successful implementation. His recommendation was approved.

Internal Audit launched the project audit using Project Pre-Check’s Diagnostic process. The assessment involved a review of the processes used to guide the SOD work and the project deliverables to date. It also involved interviews with selected members of the Working Group and additional staff in the regions regarding their views on progress to date and thoughts and suggestions on future plans. The interviews addressed the interviewees’ level of agreement on a selected subset of Project Pre-Check’s Decision Areas (60 of the 125) covering the nature of the planned change, the environment within which the change would be implemented, organizational processes and practices that could be leveraged and the management of the project itself.

The interview results showed that the SOD project’s overall level of stakeholder agreement on the project was 2.4 on a scale from 1 to 5, where 5 was completely in agreement with the decisions reached. The results indicated that the stakeholders interviewed were not in synch on the 60 Decision Areas addressed. Not a great recipe for success!

The results identified 43 of the 60 Decision Areas in the assessment (70%) as areas of divergence (at least one of the stakeholders was not in agreement with how a decision area was addressed) and 8 areas (17%) where a gap existed (where the majority of stakeholders expressed a lack of agreement). The responses reflected differing views on the scope of the project, costs, benefits, the target dates, the sponsor, project manager, decision making responsibilities and governance.

The audit took about four weeks to complete. The audit leader presented the findings and recommendations to the audit committee. The recommendations included:

Confirm the sponsor
Form a stakeholder group including comptrollers from all regions
Appoint a project manager
Work towards full agreement on all 60 Decision Areas included in the audit.

The Results

The sponsor was confirmed. A stakeholder group was formed and operated through to the completion of the project. A project manager was appointed to carry the project forward. She was a recent hire in the Finance organization with accounting qualifications and a financial background but no formal project management training or experience.

The project was delivered successfully in all regions according to the budgets and dates negotiated with the head office groups and with each regional comptroller. At implementation, all 60 of the Decision Areas addressed in the audit averaged 4 or greater, indicating very strong agreement among the stakeholders on the decisions made. All gaps and areas of divergence had been eliminated. The members of the stakeholder group were unanimous in their praise for the job done by the PM. Not bad for a PM with no prior project management experience!

How This Great PM Helped

The senior management attention initiated by the project audit and the subsequent actions taken on the audit recommendations provided the PM with a huge starting advantage. She had a designated sponsor and she had a committed stakeholder group representing the organizations affected by the change. As well, because everyone knew she had been selected by senior management to guide the project, she was perceived to have the authority to act, to acquire the necessary staff and other resources and quickly push through the needed decisions.

To her credit, the PM used those assets effectively and took the following additional actions that were necessary to get the job done:

She determined the sponsor’s expectations regarding ongoing oversight on costs, benefits and timing and on existing corporate practices that he expected to be used. She helped him articulate his thoughts on how scope, change, issue, quality and risk management should be handled and confirmed his criteria for calling the project complete.
She engaged the sponsor to review these expectations with the other stakeholders and gain their agreement, facilitating collaboration and compromise where needed.
She established roles, responsibilities and operating protocols for the stakeholder group, including the sponsor, targets, the champion and her own role as change agent.
She used the 60 Decision Areas addressed in the project audit as the basis for a report card tracking stakeholder agreement levels over time.
She modified the standard project reporting template used by the IT organization to address the sponsor’s information needs and further adapted the practices to address some unique concerns of the other stakeholders.
She worked with the other stakeholders to develop an overall plan and approach that met the overall needs of the organization and addressed the requirements of each region.
She went the extra mile to ensure the regional comptrollers from far off places (Asia Pacific, Australia and South America) were involved and up to speed on developments even though it meant some extra long days for her. It paid dividends in open and honest dialogue over the course of the project.

The bottom line: she was successful because she worked effectively with a committed, knowledgeable stakeholder group and she used and adapted existing frameworks and practices to guide the project to completion.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a situation that I call The Offshoring Challenge. In this assignment, the project manager paid the price for failing to assess the risks of working with staff from a different culture, in a remote location, in a different time zone. In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens, send me the details and we’ll have a go.

Don’t forget to leave your comments below

From the Sponsor’s Desk. Anybody Can Manage a Project, Part 1

Written by Drew Davison on October 27, 2010. Posted in Articles. 7 Comments on From the Sponsor’s Desk. Anybody Can Manage a Project, Part 1

In my last post, The Power of Teams, I reviewed a project that succeeded because the PM went that extra mile to build a great team. I also looked at how this Great PM leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results.

In this post, we’ll look at a situation that happens all too often – assigning someone with no prior PM experience, no formal PM education and no in-place mentor to manage a key project. That’s why I call this post Anybody Can Manage a Project, Part 1!

The Situation

A well-known North American financial services company provided life insurance coverage for individual customers through their brokers and agents. They used an illustration package to demonstrate insurance proposals and the related premiums and coverage to prospects and clients.

The Goal

The insurance company wanted to offer new options and features to the public and needed to make major enhancements to their Illustrations system to support these plans. It was expected that these enhancements would result in increased revenue and market share. The project budget was $1.7 million.

The Project

The organization had an IT shop of about 150 resources. The CIO decided to promote a Solution Architect to the position of project manager for this project. The business agreed with the proposal. They felt it was a logical choice – she had been with the company a long time and knew their business well. She knew all the IT and business players and was well respected. She had wanted to move into a project management position, and this would be a reward for her loyalty and hard work within the organization.

The Results

The project struggled on a number of fronts:

The project manager did not understand project management fundamentals. She had no idea how to manage a budget, a project plan, issues and risks or how to develop and execute a communication plan! What she had thought would be a piece of cake and help her gain more recognition turned out to be a nightmare.

She continued to operate with a Solution Architect mindset, working primarily with a senior staff member in the Marketing organization to design the new features, functions and capabilities of the illustration service.

The sponsor and the CIO were AWOL. They initiated the project with much fanfare and then proceeded to go onto more pressing demands. They put no oversight framework in place. Meetings with the PM were haphazard at best.

The other stakeholders – Sales, Product Development, Actuarial, Administration, IT – weren’t formally invited to participate and didn’t push to be included.

The project was out of control – scope creep, budget overrun, no proper project plan, and no direction to the team. There were project management and software development methodologies available in house with the expertise to support them. The PM did not make use of the methodologies or the expertise and no one requested that she do so.

After months of uncertain progress, escalating costs and no clear plans to assess the status of the undertaking, the business sponsor asked that the project manager be replaced in order to save the project. The business had lost all confidence in her ability to deliver the targeted solution.

Finally, an experienced project manager was assigned to save the project and deliver the required capability.

The project was delivered for almost twice the original budget, nine months late.

How a Great Project Manager Would Have Helped

In spite of the obvious answer – assign an experienced PM – it is possible for people with little of no formal project management education or experience to be successful in a project management role. The problem in this situation was the assumptions the CIO, the sponsor and the Solution Architect made about her capabilities: she knew the business, she knew the application, and she knew the players. Therefore she knew how to mange the change. Fatal!

When a PM takes on a new assignment, there are some critical questions that need to be answered about the planned change. It doesn’t make any difference whether the assignment is the PM’s first or 1001st. It doesn’t matter whether the PM has been with the company for 30 years or has no prior exposure to the business or industry. The questions great PMs always ask and get answers to include:

Who are the key stakeholders and what are their roles? Who’s the sponsor? Who are the targets? Are there any champions? Are there any other change agents involved?

What are their individual and collective capabilities and levels of commitment? Is this a critical project for them? Do they have a clear and shared vision of what needs to be delivered and how it will realize the expected returns? Are they willing and able to make the necessary decisions to achieve a successful implementation? Have they worked together before and how effective were they?

What do they want? How do they see the planned change tying into to the organization’s mission, vision, values, strategies and plans? What kind of features, functions and capabilities are they looking for and what priorities to they attach to each? How much are they willing to spend? When do they want it delivered? Do they have any expectations about pilot programs, phasing delivery, staging implementation? What kinds and levels of risks do they want to take on? What are their quality expectations?

What is the impact of their wants on the existing environment? Does the planned change alter relationships with external entities (customers, suppliers, partners, etc.)? How does it affect the organization’s products and services, processes and functions, information needs, technology infrastructure and organizational structure and relationships?

How should the change be managed? What methodologies, processes and practices should be leveraged to guide the project through to completion? What kind of oversight practices should be applied? How do we resolve disagreements among the stakeholders? Who else needs to be involved, internal or external, at what stage?

In essence, these are the fundamentals included in Project Pre-Check. Great PMs add to these questions their leadership abilities, a willingness to learn, to seek guidance, to dialogue and to collaborate to achieve success. In this situation, the PM did fail. But so did the sponsor and the other stakeholders. It was a classic case of not so benign neglect!

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a similar situation that I call Anybody Can Manage a Project, Part 2. In this case, the project manager assigned to manage a key project had no prior PM experience, no formal PM education but managed to achieve a much more acceptable result with a little help from her colleagues. In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens, send me the details and we’ll have a go.

Don’t forget to leave your comments below

Managing Complex Projects that are Too Large, Too Long and Too Costly

Written by Kathleen B. (Kitty) Hass on March 3, 2010. Posted in Articles. 85 Comments on Managing Complex Projects that are Too Large, Too Long and Too Costly

ManagingComplexProjects1 In an earlier article in the Complex Project Management (CPM) series, we introduced the topic and discussed CPM trends. We also presented the new, validated project complexity model. The model consists of nine complexity dimensions that may (and often do) exist on highly complex projects and programs. In this and subsequent articles we will discuss each complexity dimension in detail.

This article considers the unique complexities of large, long-duration, high-cost projects that pose challenges to project success, and offers both old and new management strategies to handle the complexities. Refer to Table 1: Size/Time/Cost Complexity Profile to examine the nature of these project characteristics as the size/time/cost dimensions increase.

Complexity Dimensions	Project Profile
	Independent Project	Moderately Complex Project	Highly Complex Project	Highly Complex Program “Megaproject”
Size/Time/Cost	Size: 3–4 members Time: < 3 months Cost: < $250K	Size: 5–10 members Time: 3–6 months Cost: $250–$1M	Size: > 10 members Time: 6 – 12 months Cost: > $1M	Size: Multiple diverse teams Time: Multi-year Cost: Multiple Millions

Table 1: Size/Time/Cost Complexity Profile

What Makes Large, Long, High-Cost Projects Complex?

Of the various elements that combine to make long-duration projects complex, the most significant is the inevitable changes that will occur in the business environment, which will necessitate adjustments to virtually all elements of the project. Knowing this, the successful project leadership team evolves, practicing situational project leadership, adapting and modifying their approach to accommodate the inevitable changes. In addition to adapting to change, the sheer size of the work involved for large projects weighs heavy on the project team. Research has demonstrated that the smaller the project team and the fewer deliverables, the greater the likelihood of project success. Therefore, the project leadership teams need to reduce the size of work packages to “seem like” many small projects, as opposed to one very large endeavor. As a final point, team fatigue and burnout lead to complex human interactions and unavoidable staff turnover, both of which are difficult to predict and manage.

Managing the Complexities of Large, Long, High-Cost Projects

The complexities of large projects require that particular attention be directed to planning the project, developing and delivering the solution, selecting team members, and sustaining a high-performing team over the long haul.

Planning the Project

Six important strategies for planning and structuring large, long, high-cost projects are offered, both conventional and adaptive in nature:

Adaptive management approaches complement traditional practices
Progressive elaboration allows the project to evolve
A systematic, reliable approach to estimating increases confidence and accuracy
Rigorous time and cost management increases reliability
Stage-gate management enables continuous improvement
Rigorous risk management pre-empts challenges and seizes new opportunities

1. Adaptive Management Approaches Complement Traditional Practices

For large projects, the ability to adapt is the difference between success and failure. The leadership team should analyze the situation, correctly answering questions like: Is this really a program? Is it a series of modestly scoped, small projects? Must the project or program deliver a product line, a system of systems? Can the solution be delivered in components? Only after this analysis should management decisions be made. In particular for long-duration projects, success depends on selecting the management approach best suited to deal with the changes that will inevitably occur. The team strives to recognize the nature of the problem and solution, and to understand whether the conventional, reductionist systems/software engineering and project management approaches will work effectively. Only then can we make the right choice of management approaches (e.g., conventional vs. adaptive techniques, appropriate project cycles, the best project team structure). It is also prudent to build continuous customer and end-user evaluation and feedback into the approach to ensure that the project delivers what is needed-which often is not what was originally proposed for large, long-duration projects.[i]

2. Progressive elaboration allows the project to evolve and the solution to emerge

Continuously improve and add detail to the project approach as more information becomes available. Allow more accurate and complete plans to emerge from the successive iterations of the planning process. Instead of trying to plan the entire project, start by scheduling only the activities that define firm basic requirements.[ii]Then, begin to plan activities to develop a conceptual design of the solution at a high level, resisting design decisions that will impose constraints.

3. A systematic, reliable approach to estimating increases confidence and accuracy

Estimating is hard, very hard. One precondition to being assigned as manager of a complex project should be a track record of developing reliable estimates. To increase reliability, use multiple estimating techniques. Educate your project sponsor and other key stakeholders about the fallibility of estimates in general and discuss the reliability they can expect from your specific estimates at key points in the project. Without a doubt, early estimates will be highly unreliable, exhibiting a wide range of variability. Numerous uncertainties are involved when building something unique with a team that has not worked together in the past. However, once the project has executed through a few iterations (if using incremental techniques) or through a few project phases (if using linear techniques), you can begin to gauge the speed of progress and adjust your original estimates accordingly.

4. Rigorous time and cost management increases reliability

Delivering on schedule is one of the main challenges for a long-duration project, simply because of the enormous amount of work to be accomplished. Implement a rigorous process for tracking progress and controlling output. Track progress to the next milestone or release scrupulously. Manage the schedule and budget by establishing a project support team to update and maintain the schedule and budget baselines; emphasize to team members that they should bring any issues that put the next milestone/release in jeopardy to your attention immediately.

5. Stage-gate management enables continuous improvement

Stage-gate management can be used to create opportunities to gather feedback from your customers and your team members on a frequent basis. After completing each phase, iteration, or release, conduct informal team-based quality reviews of deliverables. As part of these reviews, determine what worked well and identify opportunities for improvement to the solution development process and team operations. Subsequently, conduct a formal external quality assurance review of major deliverables and incorporate actions to correct defects found in the deliverables that must be resolved before work can proceed. Update the project cost, schedule, and scope baselines for the remaining near-term project phases/iterations, incorporating lessons learned into the plans. As part of the review process, examine the business case to validate that business benefits will be achieved and the investment is still sound. Conduct a formal project review with the project sponsor and other key stakeholders to secure approval to formally launch and expend funds for the next phase/iteration.

6. Rigorous risk management pre-empts challenges and seizes new opportunities

Few projects perform adequate risk management. For large, long-duration projects, it is essential to identify risks after each iteration/phase and re-examine risk responses to:

Ensure the risk response plans are managing known risks
Identify new risks and develop risk response plans
Identify new project dependencies and interrelationships and develop dependency management plans
Identify previously unknown opportunities to increase the business value of the solution

Developing and Delivering the Solution

Five important strategies, both conventional and adaptive, to deliver the solution on large, long, high-cost projects are presented:

Iteration is the best defense against uncertainty
Scope minimization is the key to success
Last responsible moment decision making keeps your options open
Rapid application development reduces time to market
Lean development techniques increase efficiencies

1. Iteration is the best defense against uncertainty

“Projects should always be managed by rapid learning cycles because what we are doing is so complex that nobody knows the answer to begin with.”
-T. Gilb, software engineer and author

Research has repeatedly demonstrated that short-duration projects are more likely to be successful than prolonged endeavors.[iii]Oftentimes business transformation projects involve a mix of complex development efforts, such as business process reengineering, legacy IT system replacement, and the creation of new, innovative business practices that rely heavily on technology. To increase the probability of project success, structure your project into multiple deployments of small solution components rather than taking the “big bang” implementation approach. As you develop and deliver the solution in increments, incorporate lessons learned from each increment into the next iteration and constantly test for alignment with business objectives.

The Standish Group Recipe for Project Success (Table 2) asserts that “success is practically in the oven” when a project follows this recipe. Standish reports that it is prudent to reduce the amount of resources to no more than four people, for no longer than four months, at a cost of less than $500,000. For large, long-duration projects, the only way to get the resources down to this level is to structure the effort into a program comprising multiple projects and to use incremental/iterative solution development.

Ingredients	Clear business objective; minimized scope (microprojects with rigorous configuration management); constant communication and collaboration; proven, standard, stable software infrastructure (vs. custom code); firm basic requirements; formal methodology; reliable estimates
Mix with	Full-time, co-located core team members (experienced business analyst, project manager, business visionary, architects, and developers) coached by an involved executive project sponsor, involved stakeholders, an iterative development process, and effective decision-making tools (requirements tools, project management tools, design/analysis tools, and modeling tools)
Bake	No longer than six months; no more than six people; at no more than $750,000 (1999) No longer than four months; no more than four people; at no more than $500,000 (2001)

Table 2: Standish Group Recipe for Success, 2001

2. Scope minimization is the key to success

The motto of 21^st century projects is: “Barely sufficient is enough to move on.” The more features and functions, the larger the project; as we have discovered, less is more. Initially, deliver a minimum viable subset of the full solution to start adding value for the organization as early as possible. Then, continue to deliver components of the system in short-interval deployments. Limit the dependencies between solution components to reduce the cost of changes. Design the solution to be flexible and agile to allow the customer to respond to changes in the business need, technology, or market conditions. End the project when the return on investment in additional increments is marginalized.

3. Last responsible moment decision making keeps your options open

Flexibility comes from delaying design decisions and the start of major activities for key project drivers (information flows, technical decisions, and business decisions) until the last responsible moment; that is, the latest moment possible without compromising cost or schedule. This “keep your options open” approach allows for maximum flexibility.[iv]

4. Rapid application development reduces time to market

If requirements are understood and scope is contained, rapid application development (RAD) allows for a greatly abbreviated timeline. RAD is a method of fielding multiple design/build/test/deliver teams to work concurrently. This component-based approach permits incremental testing and defect repair, significantly reducing risk compared to single, comprehensive delivery. Caution: RAD can be costly if (1) requirements aren’t well-defined, causing a high risk of requirements defects, or (2) the design is not sound, with a minimal number of well-understood dependencies between increments, which can create a high risk of integration and maintenance issues.

5. Lean development techniques increase efficiencies

Even though the project is long and complex, do not be tempted to apply more rigor than necessary. Produce documents and conduct meetings only if they add value to the project. Continually verify that the project is building the minimum viable solution. Keep in mind the motto: “Barely sufficient is enough to move on.”

Selecting Team Members and Maintaining Team Health

For complex, long-duration projects, we offer three suggestions for maintaining team health:

Select team members for the long haul
Attention to team health pays dividends
Share resources to give team members a break in the action

1. Select team members for the long haul

When selecting team members for a long-duration project, keep in mind the special personality traits and coping skills that are needed. Prolonged forced interaction is simply not for everyone. For key positions, select team member who are resilient against social burnout and psychological stress.

2. Attention to team health pays dividends

Longer projects require that attention be directed to the physical and emotional stresses on the project team members. Focusing on the health of the team, making strategic personnel changes at critical junctures to infuse new blood, and providing appropriate team leadership will go a long way in sustaining the team.

3. Share resources to give team members a break in the action

On long-duration projects, critical resources may not always be fully engaged. When this is the case, “lend” them out to a short-duration effort to give the team members a break, allow them to feel the gratification of completing a task or meeting an objective, and then bring them back to your project refreshed and ready to dive back in.

Managing large, long-duration projects

Complexities

Management Approaches

Too volatile: constant change in:
- Business goals
- Competitors
- Global economy
- Partnerships and alliances
- Stakeholders
- Project boundaries
- Business objectives
- Scope
- Dependencies
- Interrelationships
Too big: the size makes the project unmanageable, unable to identify dependencies and relationships
Too long: team fatigue set in, leading to unpredictable human behaviors

Adaptive

Adopt the appropriate project cycle and PM practices for the situation
Minimize scope
Delay design decision until the last responsible moment
Use incremental development
Use progressive elaboration and rolling wave planning
Establish a systematic estimating process using multiple estimating methods
Pay close attention to team composition and health.
Use lean techniques
Use RAD development to increase velocity for well-understood components

Conventional

Perform rigorous time and cost management
Use stage-gate management
Conduct continuous risk management
Use a systematic approach to develop reliable estimates

Table 3: Approaches for Managing Large, Long, High-Cost Projects

[i] Linda Vandergriff, Complex Venture Acquisition, 2006. Complexity Conference White Paper.
[ii] The Standish Group International, Inc. Extreme Chaos, 2001.
[iii] ibid.
[iv] Robert Lane, Vincent C. Lepardo, Graham Woodman, How to Deal with Dynamic Complexity on Large, Long Projects. Online at https://www.projecttimes.com/wp-content/uploads/attachments/32_HowtoDealwithDynamicComplexity.pdf, accessed January 2008), p. 5.

Don’t forget to leave your comments below

Kathleen Hass is the president of Kathleen Hass and Associates, Inc., a consulting practice specializing in the business analysis, project management, and strategy execution. Ms. Hass is a prominent presenter at industry conferences, author and lecturer. Her expertise includes IT strategic planning, implementing and managing PMOs and BACOEs, facilitating portfolio management, leading technology and software-intensive projects, executive coaching, building and leading strategic project teams, and managing large complex programs. Ms. Hass has over 25 years experience providing professional services to Federal agencies, the intelligence community, and various Fortune 500 companies. Certification include: SEI CMMI appraiser, Baldrige National Quality Program examiner, Zenger-Miller facilitator, and Project Management Institute Project Management Professional. Ms. Hass serves as Director at Large International Institute of Business Analysis. She has authored numerous white papers and articles on leading edge PM/BA practices, the renowned series entitled, Business Analysis Essential Library, a compilation of six titles on critical BA practices. Her book, Complex Project Management, A New Model, was selected to receive the 2009 PMI David I. Cleland Project Management Literature Award to honor the best project management literature published in the last calendar year. Kathleen Hass, PMP, Senior Practice Consultant, can be reached at303.663.8655 Email: [email protected] Website: www.kathleenhass.com.

What will Santa Bring Your Project Team?

Written by Hans Jonasson on December 16, 2009. Posted in Articles. 2 Comments on What will Santa Bring Your Project Team?

As I start writing this blog I notice that it will be published not long before Christmas. Don’t really want to think about Christmas yet, but Christmas, like a project deadline, is sure to arrive regardless of what I want to think about.

So, has your project team been naughty or nice? And if you are the Santa of the team, how do you decide who to reward and who to give a lump of coal? The black kind; not the diamond version, which would actually be a pretty popular gift. As a project manager, when you are rewarding a team member you are telling the whole team what you value.

When you reward a person who has worked long hard hours to recover your project from a mess that they created to start with, you are saying “I reward firefighting”. Of course that could mean you suddenly find yourself with a team of arsonists.

Or when you reward the whole team equally with a day off, you are saying “I feel you all contribute equally”. With the possible results that your top performers sink to the level of their peers.

Maybe you reward the person blindly following the process you have established. Now you are saying “Process is king”. This may lead to frustrated customers, inability to get things done, and lack of innovation.

Ok, this sounds a bit negative. More like the Grinch than Santa maybe. So is there a point?

Yes, the point is that rewards matter and rewards impact performance. And there are normally both negative and positive consequences of what you do. What gives positive results for some will be demoralizing for others. Before you do reward, know your people. What is the right reward for this individual? How will the reward impact performance and motivation?

But at the same time, if a person does not deserve anything in their stocking than leave it empty. In that case though, as a good manager, you must sit down and talk about your expectations and in what areas you feel that person can make a better impact on the team. This is one of the toughest parts of being a manager. But that is your job. And that is why they are paying you the big bucks…or giving you the nicest office…or providing you with a really impressive title. You don’t have any of those? Maybe it is time to sit down with your Santa (or Grinch) and find out what their expectations are of you.

Don’t forget to leave your comments below