Project Management by Anticlue

On projects and delivery there comes a time when you just need to move forward and get it out of the starting gate to the box. The ugly truth is that most corporations can't afford perfection and we need to deal with good enough. Those engaged in design, construction and implementation are focused on a flawless implementation which has minimal impacts to our colleagues. We are relentless in looking for flaws, but at what point does good enough mean move forward?

What does Good Enough Mean?

Let's look at Good enough and what it really means. Good enough is the state when the remaining flaws do not impact system adoption in a meaningful way. The balance that needs to occur is comparing functional use with the pain of deployment, and these are at different ranges.

Let's compare our ICD10 Program implementation. There will come a time when we will deploy all of the updated systems with new functionality to achieve the ability to bill in a hybrid ICD10 and ICD9 format. The date is set on when the fiscal intermediaries will be accepting ICD10 codes. Now the pain of that deployment will be large for not only will there be a large system implementation upgrade window, but also an education and training for physicians, coders, and report analysts. Not to mention the conversion of all those reports in our environment for their extraction clause especially if an Ecode is utilized.

The Take Away

The truth of the matter is that there will come a time, when it is time to move forward. Recognizing that good enough has been achieved, and any further customizations will just lead to overdesigned solutions in our search for perfection is key to a project being on time. Remaining in analysis paralysis and perfection will just delay timelines and project costs as the team looks for the panacea. As a project manager you need to be familiar enough with the risks and rewards to recognize a true opportunity to improve deployment versus a hopeless clinging to perfection.

Currently healthcare organizations have entered into the perfect portfolio storm. We have some big ones on the horizon, ICD10, Achieving the HITECH Stimulus, Assuring the infrastructure is up to date to run the HITECH Stimulus, and several growth and community initiatives within the health system. As a result, we have a lot of opportunities to take executive and operational focus away from your program. We all know programs without focus have untold wealth in resource constraints, funding constraints, and missing desired business objectives.

While adversity is a wonderful teacher, it is time to highlight on your program so it can SHINE!

How do you rise above the wave of projects and programs in the portfolio? How do you assure your program isn't lost in the crowd? It is time to take that step forward away from the crowd and branding the program is a great starting step.

Why should I brand my program?

We, program managers, have a lot on our plates, and the idea of developing a quick catchy name or an elevator pitch for your program may seem like a waste of time. Consider a moment things a little bit deeper, branding is about creating an identity for your program which can inspire team members and stakeholders. As soon as someone sees the logo or name, they instantly associate your branded catch phrase. If it something to inspire in a very tangible way, all the better. Imagine for a moment, you are in a leadership position reviewing a program update. In your organization there are several key cultural issues, and the lack of funding is generally a problem. What is the first item that enters your head when you hear One Team, One Mission? Now how about the Email Services Consolidation Effort? Just for a second, your first thought might have been positive and enlightening - a good starting place. Additionally the communication is now associated with your program.

Another benefit of branding is the team building opportunity. A brand should not be created in a vacuum, it should be something the team derives and owns. Quite often in projects, it is the first time a team begins to work together. As the team develops from forming to performing, how about engaging in a branding exercise while in the forming stage. After all the storming phase is the phase when everyone is feeling each other out, Having a discussion on branding and developing a brand is a good way to set the stage for dealing with conflict in a good respectful way and to have the team work towards a common goal delving into the details of the importance of the program. The resulting branding effort will help the team have their first true sense of ownership and empowerment on the program, plus distinguish it from the plethora of other communications.

From the outsiders or stakeholders window view into the program, a brand is a quick way to identify program related information. It is a simple way to relate the communication to the program, and help to keep the program on the stakeholder's radar screen. Now the next step is getting the stakeholders to care about the program.

What does your brand stand for?

So how do you have your brand trigger connections with the motivational values of your colleagues and stakeholders? Illustrate the benefits and business outcomes which will come from your program. By tying back to the share vision of the program, colleagues will want to be affiliated with the program's potential success. To assure the association, you and your team need to clear and consistent illuminating the benefits the program will deliver. Overall this helps to keep everyone on the same page and driving towards receiving these benefits. Here is an excellent place to lead by example, so assure you are walking and talking what your preaching. Additionally it will be helpful for the program leadership team to have the same talking points. Taking an hour and crafting talking points will be well worth the effort.

The Take Away

Branding your program is a way to share the vision of the program, distinguishes all program communications, and associates the program with core values of the organization. Its always to show what the program is about and what the team is accomplishing. Branding will be the first step to help achieving the focus of the organization on your program.

Projects are no longer managed in a vacuum. Within Information Technology, we often have dependencies to other projects. The time has come to take a program approach to managing multiple inter-related dependent projects.

Focusing upon the infrastructure side of the house, often you are placing a foundation to run the applications which automate the business. Upgrades and enhancements are needed to the infrastructure to support the applications. This is why it is important to have the program perspective and have management at the program level.

Consider the following case study, in order to prepare for the implementation of an EHR what basic components need to be in place. Your connectivity to the datacenter at the hosting location. An encrypted Wireless Network needs to be deployed. Devices like Workstation on Wheels, tablets, and touchscreens will need to be rolled out. Perhaps a thin client solution like Citrix will handle the blips as physicians traverse access points. The end result is that while each of these projects are important the desired outcome relies upon them all being achieved.

By implementing an IT Program Management Methodology, there will be key efficiencies realized. A similar project management methodology will be achieved. The same procedures, processes, and control mechanisms will be utilized by the project managers. There will be a transparency to the relationships and dependencies between projects. The ripple effects of changes will be evaluated before a scope change is made. A variation can be managed and accessed proactively.
However, obtaining this attitude of achieving for all rather than achieving for one will need to be carefully managed. Vendors, sponsors and other stakeholders will need their concerns and expectations understood. These groups will need to see the benefits and value of using a program approach to timing rather than focusing on an individual project perspective.

In conclusion, concerns will arise and need to be managed. However the benefits of grouping several foundational IT projects into a program perspective will help to achieve the desired outcome versus pieces and parts.

We have all heard the war stories of failed projects - Scope Changes running out of control, Budget Overuns, Lack of System Adoption, Automation Failures, and Live Events with fundamental system errors.

But how is project failure determined? When is the tipping point between a success and failure? Why do projects fail? Often hindsight is 20/20 and the key reasons for project failure are clear to the beholder. Consider this tale of two Ambulatory EMR implementations in different physician practice organizations. Both practice organizations have approximately 30 physician offices. Both Ambulatory EMR Implementation projects are about 2 years behind schedule. Then the likeness stops, ABC implementation has provided new equipment and installed basic result reporting in 5 sites. The XYZ implementation has provided new equipment, implemented a centralized billing office, and implemented results, orders, documentation, and e-Prescribing in all offices. Which one is a success? Which one is a failure? Surprisingly, ABC is perceived at a stunning success while XYZ implementation is described as a failure.

Let's expand upon what exactly is project failure and examine the common characteristics which cause some projects to fail.

Defining Project Failure

A project is considered a failure when it has not delivered what was needed according to expectations. A project is considered a success when it delivers the desired business benefits according to cost, schedule, quality and risk constraints.

Unfortunately, those definitions do not crystallize what is needed for project success, because success is achieved according to the manage expectations of the organization. In the above scenario even though project XYZ has delivered everything which was in the project requirements it is still consider a failure because it didn't include the vital elements for sustainability that the stakeholders needed. How key stakeholders perceive the project deem its success or failure.

Continue reading "How to Avoid Project Failure"

Most projects are about implementing some type of change. This change will need to be adopted by the organization in order to be a success. Changes are often lead by Change Leaders and the skill set to make a change stick are among the softer skills of a project sponsor. We have all experienced good sponsorship and sponsorship which needed improvement. Matching the project sponsor to the project manager and the project is crucial for the project's success. We have discussed previously the 5 key responsibilities of a project sponsor, but let's expand upon the softer skills of the project sponsor.

The main role of a project sponsor leading a change effort is to assure expectations are understood by stakeholders and to hold people accountable to achieve the outcomes. This holds true whether the sponsor is an executive, mid-level management, or a front-line manager.

The Key Qualities of a Project Sponsor

• Truthful Realism - The rose colored glasses should be removed. If there are problems, they should be transparently managed. The truth should be told, not the truth with a lot of marketing spin.
• Leadership by Example- Implementing a change should not be a do as I say not as a I do mentality. If the sponsor is asking for a get out of jail free card on the new process it will not be adopted. The sponsor should lead by example being the first to truly adopt the change.
• Reinforcing Changes- The sponsor should be able to maintain the change over time by reinforcing behaviors and implementing monitors. For example, implementing bedside medication scanning Is a great accomplishment, but having a control process which monitors the entire hospitals scan rates by service will be helpful. Having the CNO discuss with the nurse managers the process and have accountability cascaded through goals will assure the desired results are achieved.

The Take Away

The project sponsor often depicts the softer skills of a change leader. When implementing change, it is a good idea to have a change leader at the helm.

On projects decisions matter, timely decisions are crucial to project results and team performance. Wise project managers are skilled in the art of facilitating decisions. Often we find ourselves in situations where a decision Is needed to evaluate a change, determine which path is route best for the organization to support the outcomes. We all know how frustrating it is to wait for a decision only to find that the date needed for the decision has long since passed, and it is going to be a marathon sprint to make up lost time. What can you do as a project manager to assure you avoid these pitfalls?

Decision Making Approaches

First, have a good understanding of how decisions are made within your organization. There are several approaches to how organizations make decisions. The tradeoff is often the amount of team involvement compared with the time needed to make the decision. Let us take a look at the different decision approaches

• Majority Rules - With majority rules, there are often winners and losers. This approach is effective, but needs to be used with discretion.
• Consensus - Consensus building takes a bit of time, and there is a lot of negotiation among teammates. It definitely improves collaboration and has buy-in from across the team.
• Small Group Decides - Having a small group decide commonly takes a small committee is elected to research, analyze and determine the best decision. The election to participate in the small committee will be either rank or subject matter expertise, depending upon the purpose of the group
• Leader Decides with Input - Often used by leaders with decision making authority, they have a trust council of leaders who provide insights, advantages, and disadvantages of an approach however in the end it is the leader's accountability for the decision.

On projects it is a good practice to establish decision authority protocols reaching consensus among the team, stakeholders, and sponsor. It is also good to keep track of decisions needed, by whom, and what the decision was. Have a way to provide good information so that good decisions can be made.

Eliciting Decisions

Sometimes the Teflon aspect of leadership arises, and a leader is reluctant to make a decision or accept accountability. In these situations, don't drive hard for the decision instead determine what the barrier is to making the decision. Barriers come in many forms such as there may not be enough information to the leader is not empowered to make the decision. Taking the time to determine the barriers and developing a tactic to overcome the obstacles will help bring about a good decision in the future.

The Take Away

Decision making must also be fair and done by a trusted source while striving to maintain team commitment. Having decision protocols as a part of your project's controls will help to encourage collaboration and good decisions, it is a tool not project manager should be without.

Let's be frank, we, project managers, are fascinated by project failure. Mostly, due to the fact that we do not want our projects to fail, so how to avoid project failure will be forthcoming In my experience, I have comprised a listing of the top 10 reasons for project failure. Please feel free to suggest additional reasons or share your experiences. Its great to hear from you, without further ado.

10 Most Common Reasons for Project Failure

1. No Connection between the project's outcome and the organization's strategic or tactical priorities - When looking at what the business was trying to achieve with this project, it turns out to be a pet project which doesn't help to achieve the organization's strategic plan or even tactical priorities
2. Bad Project Sponsorship - The project sponsor has a close relationship with everything but this project. The project sponsor won't touch or talk about the project with you.
3. Missing in Action Project Champion/Advocate at the Senior Leadership Team- It becomes obvious after a leadership renewal or before that process, the only advocate for your project is a supervisor several levels down on the management hierarchy. No one in the senior leadership team understands the benefits to the organization of this project.
4. Ineffective StakeHolder Engagement - For these projects the impact to the stakeholders is right below everything else. There is no consideration to stakeholder buy-in or engagement in the project plan. When speaking of the Change Transformation Framework, you glance over significant blank stares.
5. Poor Project Management - There is a lack of sophisticated project management. Executives mistakenly believe project managers are just glorified documenters.
6. Worthless Risk Management- When bringing up a Risk Identification session to your sponsor and management, you hear the comment why would we want to talk about what bad things could happen?
7. Large Work Tasks- In reviewing the project schedule, you notice that most of your work tasks are above a week, sometimes even a month in deliverable time.
8. Penny Smart Proposal Review - Save Money, Doesn't matter how much it costs later. This comes up at the most convenient I beg your pardon moments. In reviewing the contract, you notice that your financially stable organization has leased equipment for purchase at 15% rate, or perhaps we are delaying on boarding those critical staff members, to save a bit of money right now - never mind there is no one to do the work.
9. Non-existent team between the customer, it, vendor - When you talk about a performing team including the customer, it, vendor you wonder why you can never ever get any two of the three parties in the same room or conference call.
10. Poor vendor governance - In discussing vendor management and governance, the item is why do we need to setup this relationship, it is just so much better to blame it on the vendor when everything heads south

If you enjoyed this post, you may want to also consider reading:

• Top Ten Signs your IT Organization is Misaligned


• The Top 5 Reasons PMOs Fail


• Three Levels of IT Leadership Based Upon Organization Sophistication

By myself, I can envision a future, with a team we can make the vision occur and greater than one imagined. In today's world, projects are completed by interdependent empowered specialists. Business objectives are achieved by the collaborative efforts of teamwork. The team maybe comprised of individuals across departments, but the individuals are accountable for facets of the overall goal.

This is why it is critical to develop a well performing team including the sponsor. Teams which are subdivided with a "me" versus the "others" mentality need to be transformed into teams which celebrate the differences, matching the right skill with the right deliverable. Individuals on the team need to be trusted and trusting. Once a task is appropriately assigned, the individual will need to be able to complete the task at hand. If It is unclear, the individual should feel comfortable asking questions of others. If there is a red flag, the individual should feel comfortable and have a know venue for raising the flag. The individual should not feel the need to circumspect and redo other teammates work because of different approaches. Checking in to assure there are opportunities to share progress or ideas with the team is welcomed and the purpose of project status updates.

As a project manager, one is aware that only collaborating with others can the end goal be realized. An atmosphere of trust and accountability needs to be in place in order to develop teamwork. Design opportunities to develop the team including the vendor, sponsor, and business departments and watch the relationships develop. At the end of the day, when you are looking to measure and qualify success, and performance improvement opportunities, be sure to keep in mind it's a team effort. Measure the collaboration of the team in the customer satisfaction survey, not did we do this, do that or do this?

If you enjoyed this entry, perhaps you would also like:

• Team Work in IS
• Establishing Team Rules of Engagement at Project Launch
• Engaging Stakeholders in Defining the Problem
• The Five Key Responsibilities of a Project Sponsor

Lately there has been a bit of discussion about the technology expertise a project manager needs to have. After the events of this past week, I even found myself considering the need to read up on storage area network, telecommunications and networking - perhaps just a quick review of the basic Cisco CCNA books. From a technology understanding perspective, these are my weak points.

Stepping back again, I'm considering why this understanding is needed. One does need to have a basic understanding of which widgets are needed to connect a business to business network connection. It is also good to have a sense why it is needed to obtain bandwidth utilization, understanding growth for the next couple of years, and then place the order for the circuit. As one explains these scheduling needs to the program sponsors - especially perhaps when explaining the need for escalation funding for a circuit order.

For a while, I have been a truly business-focused pm, we discuss how to achieve the desired business benefits early in the planning process. The implementation is completed, and the organizational change process kicks into full gear. We plan out our approach to the organizational change as we move from paper to electronic processes. After all the overall desired business purpose is what we are trying to achieve.

Truth be told the level of project management an organization desires is the level of project management they will receive. Often as we move from project management maturity levels a larger organizational change is occurring. I empathize with the pm being tagged to lead the march towards meaningful use and achieve new levels of automation in organizations which have chaotic project management and a capability maturity model of 1.

However, our mindset is within our control and is it necessary to be business focused or technology focused. After all the different tactics for the mindset are listed below:

Technology-Focused	Business-Focused
Projects are driven to stand-up a commercial product.	Projects are driven to achieve business benefits.
Delivery is measured by project milestones	Delivery is measured against stakeholder value.
Focused upon implementing an application or technology	Focused upon realizing a business opportunity.
Project Schedule is lifecycle focused either software development, system development, or infrastructure implementation.	Project Schedule includes achievement of organizational change initiatives
Success measured upon the successful rollout of the application	Success measured upon realization of the business benefits

Perhaps the truth of the matter is now a days that the PM needs to have both. After all how would you drive adoption of the new workflows for improving patient care if the beside medication barcoding wasn't there? Maybe it is just best to have all techniques and approaches within your toolchest. There are other tools than just a hammer. And if all you know how to use is a hammer, everything looks like nails.

Have you had a similar experience? What did you uncover for yourself? If you enjoyed this post, you may want to check out these other posts:

• Top Ten Characteristings of a Chaotic Project Management Environment
Improving your Healthcare IT Credibility by developing your project management maturity
• Levels of Project Management Maturity
• IT Value - Is IT an expense center or a value center?

PM Documentation which is filed away in the laptop isn't worth the effort to type. I am often surprised how those new to the project management field create documentation in silos alone at their desk just to achieve a requirement. The purpose of project management documentation is communication. The documentation should be the outcome of meaningful dialogue with the business owner. Let's take the example of a project charter and protocols.

The first section of our project charter is the high-level project overview. It captures the history, purpose, business benefits, where we are, and where we want to be. These are great topics of discussion to have with the project sponsor, project champion, and executive sponsor. It is the time to get everyone sharing the vision of the desired outcome. These ideas should not be captured in a vacuum.

The TakeAway

If you find yourself creating documentation just for documentation's sake, take a step back and reconsider how to get others engaged in the conversation. The purpose of the documentation is the communication and shared understanding needed before it can be derived. If you are missing that component, the conversation needs to happen.

Bad estimates lead to bad cost projections which ultimately equate to poor delivery. The problem being when estimates are needed for efforts to be completed to project costs. Often a project is estimated for resource effort before it is budgeted. Therein lies the problem. The estimator is rarely the individual doing the work and the amount of work may not be fully understood. Another issue is the skill of the individual doing the estimate, the work it takes one individual to do in 12 hours may take another individual 4 depending on the experience and talent. However your individual with 4 hours is probably backloaded with work.

The best estimates often come from the individual accountable for doing the task at hand, there is a sense of ownership among the team and individual of the estimate. There is also a shared understanding for how the project work was estimated. So how can we get better estimates in Healthcare IT?

3 Tips to improve estimating practices

1. Ask the vendor - Often if you are purchasing or implementing a system, during contracting ask the vendor for the amount of effort. Good vendors will share their resource estimates and effort. I know McKesson and Cerner have these to help the organization understand how much effort they need to pony up. Poor vendors will tell you that they do all the work. Truthfully, in my almost 2 decades of experience, I have never been engaged in implementing a system where the vendor did all the work.
2. Have the resources accountable for implementation assist with the RFP evaluation- The best way to bring your team is to have them partake in the RFI, RFP efforts. During the evaluation of the RFPs, have them estimate implementation efforts. Not only does this help have a solution resolved upon a needs assessment, but the requirements are now known.
3. Always have staff do the estimate - While it may be hard, let staffing have the final estimates to verify and assure they are comfortable. Once on a project all of the estimation was completed by a senior technology director. This individual was new to the organization and not familiar with how interwoven the old technology (Novell File Servers) where to the organization. The estimate provided to retire was way too short of a timeframe and didn't consider some integration points with the mainframe. Having the staff review the estimate and rework it, provided an opportunity to properly frame the project effort

The Take Away

It is best to deploy all three of these practices to improve the art of estimating. Having better estimates will help with the overall portfolio health, and decrease the amount of technical debt incurred.

We will be offering the The Accidental Project Manager Web Education program on 3-Feb-2010 2:00 PM EST - 3:15 PM EST. There are still a few spaces available, so we would like to offer you the opportunity to reserve your spot, please click here to RSVP.

Over the last decade tools and strategies that enable Successful Project Management in organizations have developed and evolved. While there is a vast body of knowledge available on the topic, what do you do when you are thrust into the roll unexpectedly?

This presentation will review an overview of tools and practices available for successful project management and the "Must Do's" when resources and time is tight. Attendees will gain an understanding of how to use the project management process to help assure that your project is delivered on time and within budget.

I'm looking forward to having a good webinar and collaboration with other. Hope to see you there!

Let's say you are in a new role and a new organization, isn't it nice to have an onboarding process? This gives you the lay of the land, what you need to use, how information is disseminated, what your role is and how it relates. The same type of mechanism should be done at the project kickoff. As the project manager, it is your responsibility to assure the whole team is brought on board with expectations managed, an understanding of their part, and guiding principles to assure project success.

The tool many PMs use to bring everyone to the same place of understanding is often referred to as Rules of engagement. The rules of engagement can be viewed as the foundational step in forming.

Rules of Engagement Roadmap:

• Roles and Responsibilities - Roles and Responsibilities lay out what is one's accountability and function in the project. This can be in the form of a RACI chart.
• Escalation Process - Laying out how issues and problems are escalated is a critical success factor for any project. At the beginning it is a good idea to clearly identify how and to whom escalation is done across the project team.
• Project Protocols - Project Protocols are the standards for how meetings, issues, risks, changes, schedule and costs are managed within the project. PMI labels this as the project management plan. I try to have it be guidance for employees
• Guiding Principles - Guiding principles are often the most overlooked aspect of the rules of engagement. These are the core principles which help cement the team's outlook and perspective towards the overall goal. For example:
  • We will looked upstream and downstream for impacts in our analysis and assessments.
  • We will challenge each other's ideas in a positive productive manner to help bring about the best solution for all.
  • We will respond within a business day to email or phone queries from our teammates. If we don't have an answer, we will acknowledge the query within a day with our inability to assist and help of where else to check.

The TakeAway

The value of understanding your part in the project helps to set expectations and clarity. The time spent constructing and developing roles and responsibilities will help launch your project successfully, just always remember this is a collaborative process not dictated in most instances.

Please feel free to share your stories of how establishing rules of engagement have either helped or hindered your project. As always your suggestions are welcomed and appreciated!

If you enjoyed this post, you may want to also check out these other similar entries

• Tips of the Trade - Clarify Roles and Responsibilities


• Engaging Sponsorship - Team up during project launch


• The Five Key Responsibilities of a Project Sponsor

At what point is it good practice to be transparent? At what point does too much transparency look like a lack of control? A part of managing a project is to disseminate information by being the spokesperson for the project, another part is to handle disturbance and mobilize the team in support of an issue. The act of balancing these two components is where transparency happens.

Let me share a tale, we were in the middle of a groupwise to exchange conversion for the email system. We had hired temp contractors to help with the mailbox migration. As a part of the conversation, we migrated the executives mailbox and calendars during the evening hours. When the executive assistants arrived the next morning, all of the calendared appointments were migrated an hour earlier. They quickly alerted us to the problem, as we had asked them to validate first thing in the morning. Now the time when you can use the rope to either make yourself a lasso or a noose. What you communicate, how you say it, and when you say it is crucial. When is it time to be transparent?

The 5 considerations for Timing Transparency

1. Listen to the impacted customer and have a plan to address their concerns - It is important to take time and hear the problem, often this is done via the war room helpdesk. With executives and executive assistants, visiting, watching, and listening is important. If there isn't a quick fix, honesty is important, but so is control. Set up the best way to communicate resolution and progress. Also see if there is a temporary work around for right now. If the problem is net new, transparency as to the cause and approach to resolution should be focused upon research and when to get back to the affected individuals.
2. Don't let the upward management chain be surprised. - Another key is to not let your director or CIO be surprised. If the problem is at the executive level, it is best to communicate using your chain of command. In most cases the management team will be supportive and help facilitate the executive's problem resolution. Transparency here should be around getting the team engaged and working towards resolution.
3. Assure the team is aware and focused upon resolution. - Assure the team is aware, in most cases, they will have creative and good solutions to resolve the problem. If they engage in a blamestorming behavior, it is time to re-group and get the team focused on problem resolution. The pm should be clearly transparent with the team of the problem. Establish check back in points, so the team can work but you as the PM are aware of progress and obstacles. As the pm, facilitate the removal of any obstacle, and be prepared for good communications to the customer base.
4. Have scheduled controlled communications to the executive suites. - As a part of accountability, be sure to have consistent informative communications with the executive suite. Assure the communicate is fine tuned for the audience, and has an anticipated resolution time if there is one.
5. After the problem is resolved, assure it never occurs again - After the firestorm, it is a good item to look at what happened. Find out why it occurred, and what could be done to prevent the problem again. In the above scenario, the machine doing the account migration had the wrong time zone. This was removed by adding a double check to the timezones, when setting up a migrating machine. The added quality control should be communicated to your leadership chain.

Hopefully you enjoyed this post, you may also want to check out:

• The four key approaches of Lean Six Sigma for Healthcare


• Understanding Healthcare's Seven Categories of Waste


• How to do a waste walk with Strategic Intent


• Talking the lean jargon

If you are the project manager of a project which has absolutely no benefit, it is time to jump from the train before train wreak. Seriously, let's look at this scenario:

The new department head wanted a new system, because she loved using it at her old job. Operationally she requested and received funding was ready to go. After the planning was done and during execution, the project manager realized that there was an enormous risk to adoption with the physician community. It was not conveniently interwoven into the workflow. As the rollout continued, resentment from the floor towards the system came to light. Staff repeatedly mentioned the cumbersome nature of the new system. When asked about the benefits, the department head related how it benefited her old job. Several staff whispered on how those benefits where already achieved due to workflow and process improvement changes, without the system. The anticipated increase was a lot of squeeze for little juice. During training, the pm and the sponsor tried to rally the adoption of the system, but the value just wasn't there. The physicians were very vocal at the executive level for wasting money on a cumbersome painful system, with limited integration. After rollout, adoption issues continued to plague the project team. The concept wasn't valid in this environment and as the staff had said stated the anticipated benefit realization, did not occur.

Unfortunately, in an environment without a good governance process this tale is far too often heard. Everyone's time and effort is of value. If you hear about a project like this tale, in a leadership role, investigate it. If the conclusion is that the project has no value or benefits, be politically savvy, and try to get the project to a state that it has value -Credible realistic value. Because honestly, at the end of the day, a project with absolutely no value disheartens staff, wastes money and time, and causes credibility losses, all of these are reasons not to move forward with such an endeavor.

So how do you help this project? As a pm, I would take some time with the sponsor to review the assumed benefits from the business case. Take the time to check the current state of the benefits, to establish a baseline. After wards discuss the findings and how to achieve the assumed benefits, then detail about in a benefits realization matrix the desired goals. Once this matrix is agreed to by the sponsor - communicate it upwards and out to the stakeholders. If there are still no benefits, and a political nightmare, as the pm I would have an honest collaboration with my boss on what I see occurring. I'd request help for the current situation. Most good managers and directors will see the problem and help bring it to resolution.

Further Readings on Taming Chaotic Project Management:

• The Top Ten Characteristics of a Chaotic Project Management Environment


• Find out how many active projects are in flight.


• Establish your organization's current and desired need of Healthcare IT


• Collaborate on Prioritization Decision Criteria


• Have a defined and approved process to accept work.


• How to stop running the daily meeting marathon


• Using the WBS to define deliverables


• How to know when you have a project and when you do not


• 8 Training Tips on how to develop project schedules


• Introduce a Scope Change Management Process


• Introduce a Benefits Management Process


• Top 5 benefits to a project dashboard


• Growing up from a functional to a matrix model

While planning a project, there are decisions which are based upon presumed truths. These presumed truths need to be in place for the project to be successful. As a project manager is it your responsibility to manage the assumptions within your control and properly escalate others.

Assumptions are those common placed truths which have a nasty habit of wacking the project execution with a wreaking ball when they are found not to be true. So let's talk about some common place assumptions in healthcare projects.

Common Assumptions in Healthcare Projects

The department is supportive of changing how they work

The product is stable and able to quickly change to meet our needs

The technology is well known among our it department

The technology will work with our legacy infrastructure.

Everyone is available for training and testing whenever needed.

Managing Assumptions should be aligned with how you manage risks, the key here is to assure the assumptions are transparent, well defined, and have an individual accountable who is empowered to assure the assumption holds true.

There are three key practices in managing assumptions:

1. Identify Planning Assumptions - We first start by reviewing business case, charter and high level scope definition. Here we pull out those planned truths. Don't just stop if there is a section, labeled "assumptions". Review all existing documentation for assumptions. Once you have them, let's be sure to clean them up. Applying our smart methodology to assumptions, resources will be made available as needed becomes. From October through January, the nursing manager, director of medical informatics and 2 system analysts will review the future workflow. The resources will commit 8 hours a week to this effort which will be measured by reviewing the time logged and deliver a completed workflow for each service on a bi-weekly basis. Now let's place these either in our RAID sheet or our risk register.


2. Analyzing Planning Assumptions - The next step is to review the assumption, determine a leading event to show that the assumption is failing. For example on the above if the weekly workgroup meetings are canceled, there is a high probability the output will not be obtained. Also identify an accountable individual for managing this assumption. Here it would not be project manager but perhaps the director of nursing and medical informatics. If this does not happen, what is the impact to the project.


3. Develop Action Plans - Here is how the accountable owner of the assumption will be managing it. Perhaps there is a control put in place, like a notice to the directors before the meeting is cancelled to eliminate the conflict, or another standing meeting has time carved out to make the participants available. If this is going to be a continual problem, perhaps another resource is assigned to walkthrough the new workflow with each participant individually, with a 3 day turnaround for agreement.

If you enjoed reading this article, perhaps you would also like:

• Pre-Charter


• Checklist of Charter Components


• Quick Little Risk Management Checklist

Principles set the stage for how something is to be used. We have guiding principles of IT to help organizations understand how to utilize and get value from IT. Along a similar scale, Agile project management has principals to guide usage. In reading the list, it sets the stage for a collaborative creation of something which will be fined tuned into a singing fully adopted tool.

The Nine Principles of Agile Project Management are:

• Deliver Something Useful
• Cultivate committed stakeholders and sponsors
• Employ a leadership-collaboration management style
• Build competent collaborative teams
• Empower team decision making
• Use iterative, feature-driven delivery
• Encourage adaptability
• Champion technical excellence
• Accelerate throughput

Enjoy this entry? perhaps you would also like:

• Knowing when to use agile project management
• Principles behind the agile manifesto

The motion computing C5 tablet with gorilla screens are a great concept. The project is one in healthcare which was developed progressively by exploring and adapting the product in a clinical environment. This is one of those times when it was good to use Agile Project Management.

Agile Project Management's LifeCycle Includes five phases:

• Envision - ascertaining the product vision, assigning accountability for who will be doing what, clarifying roles and responsibilities, and laying the foundation in how the team will work together.
• Speculate - discerning the feature-based release, milestone, and iterative plan.
• Iteratively deliver features - deliver the tested features in quick turnaround timeframes
• Monitor and Adapt - review the deliverables, the current business environment, and the team's performance - and make changes as necessary
• Close - conclude the project, resolve any outstanding items, and reward the team.

Agile Project Management excels in three main situations:

• Projects which are exploratory in nature
• Project which need to have a high degree of customer collaboration
• Projects which have teams which are highly innovative

For healthcare project manager, Agile is ideal as a mechanism to get the system adopted in the daily life of our clinical colleagues. After the initial big bang of the implementation, an agile methodology can be utilized for clinical rule deployment. The goal is to make certain the rules augment clinical decision support by following the CDS 5 rights model in a quick manner. All of the principles of agile project management are present in the continuing enhancement of the system driving implementation. We are focused upon the practicioners needs and pain points, constructing rules to fulfill needs and remove pain points. This methodology which is explorative and adaptable is a great fit for enhancing your clinical system.

Further Readings on the Getting Ready for Meaningful Use EHR:

• Accessing your nursing organization's capacity for change
• Assessing your current infrastructure
• Using Rules to support clinical decision support
• Assessing your vendor management skillset
• Assessing your project execution ability
• Discovering the organization's perception of an EHR
• Getting your physician leadership engaged
• The 5 levels of healthcare IT Credibility
• Understanding the refinement of meaningful use

We have all heard that 90% of a Project Manager's job is communication. Communications take a large part of a project manager's time, and it is crucial to convey information effectively. Information is constantly streaming at us continually via email, twitter, smart phones, and instant messaging; individuals have even started writing about slowing down the rate of communications. Hence it is important to keep in mind that it is the responsibility of the communicator to assure the message is timely, understood, and resonates.

As a project manager, here are some ways you can use to communicate effectively.

1. Talk with the receiver about the best mechanism and timing for them to receive information - With sponsors, key stakeholders, and key team members, it is good to have an open and frank discussion about how best to give them updates, obtain status, and assure they are prepped for when they need to communicate.


2. Write emails for the audience receiving them. - For projects there is the ground on the floor knowledge for those involved in the day to day, the view of the countryside for those viewing the larger picture, and the plan view for the executives looking to achieve the strategy and outcomes. The email to the day to day team, will be too detailed for those looking for the 1000 ft view. It is wise to consider your audience for the email, and not to send an email meant for one audience to all others just for a couple extra minutes of time. The time made up will be lost as you have to answer questions which arise.


3. Pick up the phone, schedule a drop by, but make an effort to talk - There is written and there is verbal communication, and if you are located in the same next of the world. I'd highly recommend touching base in person with people. Make an appointment, have an agreed agenda, then walk it. Also observe individuals reactions and body language.


4. Watch for signs that your point was not received - Once the item was communicated, have signs it was received. Once, I had a supervisor who would only recall items which made it to her daily schedule or folders which she carried. There was a pile on the desk, and another pile on the floor. However, if I got a note in her daily schedule or the file added to the bag The discussion had made its way home. If the paper got placed on the desk or on the floor, I knew I had to come back another time and try again. Today was not going to be the day. Be observant for patterns of behavior indicating definite reception.


5. 3 ways 3 times - There is a discussion that individuals need to receive a communication 8 different ways, 8 different times in order to understand it. I'm more of the opinion if you can communicate in ways which resonate, 3 ways and 3 times are the charm.

Hopefully these tips will help you improve your communications, they have been helpful to me. Please share other suggestions below on improving communication effectiveness.

Further Readings on Tips of the Trade:

• Ways to Improve Communication


• Communication Barriers


• Dealing with operational risks


• Minimize Conflict using these three tips


• Why taking and distributing meeting minutes is a necessary evil


• Giving and Acting upon a customer service survey

As you begin to move from a Chaotic Project Management Culture, one of those struggles for the organization is going to be how do I know when do I have a project? PMI's definition is a bit nebulous for the staff trying to accept a project management methodology. PMI defines a project as a temporary endeavor undertaken to create a unique product, service, or result. Those trying to understand the project management methodology take a little bit for the enlightenment light bulb. Those passive aggressive dissenters never cross this river and use this concept as a political barrier.

However, the good news is that this obstacle is easily overcome. The easiest technique is to provide a pm cookbook recipe approach.

I know I have a project when several (not all) of these conditions are met:

• I am going to need a team of people to get this done


• I am going to need to tell my boss and my customer the progress of this over a month or longer


• I have a business executive who wants to get this in to improve the way his department works


• Our goal is to provide this objective by adding this or really change that to this


• I am really going to need to coordinate everyone's task to get this done


• Someone has to keep track of the funding to buy and install this


• We are creating or installing something net new, which we have not done before here


• I am going to have to train people to use this

Further Readings on Taming Chaotic Project Management:

• The Top Ten Characteristics of a Chaotic Project Management Environment


• Find out how many active projects are in flight.


• Establish your organization's current and desired need of Healthcare IT


• Collaborate on Prioritization Decision Criteria


• Have a defined and approved process to accept work.


• How to stop running the daily meeting marathon


• Using the WBS to define deliverables

Too often in our industry there are discussions overheard about how the new system has little value, its adoption within the facility or organization is poor. What the system does is not up to par with what the organization needed and anticipated. Assuring this gap is a sidewalk crack versus a chasm is all about the quality of the deliverables.

People desire outcomes, the tools only assist in bringing about the outcomes. However individual's perceptions view the outcome and determine if it is valuable. Implementing a full CPOE is good, only if the wireless throughout the house works, and physicians computer access is beyond the one in the physicians' lounge. Otherwise it really isn't usable and not worth the intrusion to the physican's day. I define the value creation gap as the gap between what was anticipated and what was delivered.

Perceptions of value are made upon expectations, managing expectations is a large part of the project manager's communications. Project manager needs to be curious and inquisitive to discover the sponsors and stakeholder's perceptions and desires. This practice is known as constantly minding and closing the value creation gap.

Continue reading "Tips of the Trade - 3 Techniques to close the Value Creation Gap"

One of the first steps according to PMI is to assign the PM in initiation. As the PM, the first thing I need to know is who the Project sponsor is. Engaged Sponsorship is critical to the project success. I'd like to share with you a few tips of the trade to help assure a fully engaged sponsor during the project launch.

The first tip in today's entry is to openly and frankly discuss the business benefits this project is trying to achieve. If there are no benefits, the business really shouldn't engage in the project. As a PM, I like to have a good understanding of what is needed to achieve the benefits. I also like to have some preliminary work or metric on where we are today. I enjoy hearing the sponsor's vision of a day in the life in the future. What improvements or opportunities we are focusing upon. This discuss is well worth the time, and it clarifies the vision for both of you. Sometimes if you are really lucky it will help to clarify what the sponsor is passionate about pertaining to their job.

The next items, I like to review are the standard project management processes. Here the discussion is surrounding how the project will be managed and the sponsor's agreement. We talk about scope change control process and at what authority levels decisions can be made. Reviewing and deriving a common escalation pattern, who to escalate what type or issue. Finally we talk a little about business versus technical issues, and an approach which would work for this project. Its nice to have business issues escalated to the sponsor.

After this preliminary discussion, I follow up in anywhere from a couple of days to a week. Asking if there are any concerns, commonly this meeting is to review the project team roles and responsibilities. We talk a lot about the change transition or business transformation from the new to the old way. The risks that the sponsor or myself foresee, and who should be accountable for those risks.

In practice I have found the first time, these discussions are received well, and they also truly set the project up for success. Everyone is comfortable understanding their roles.

Futher Reading:

• The five key responsibilities of a project sponsor


• Engaging Sponsorship - Starting off on the right foot before project launch


• Achieving physician leadership engagement

Recently, I received a question of how does one know they are ready for the PMP exam. My best assessment for you is to first understand the earned value formulas (more than memorize) and are able to map out from memory the process groups and knowledge areas. I would then recommend taking some sample test questions. Use the test as a tool to identify the areas which need improvement. When you are above 80% for the practice exams, you should be in good shape for the test. Some good free sample test questions can be found online at the following sites:

• http://www.oliverlehmann.com/pmp-self-test/75-free-questions.htm - These are good questions, and it is offered as a great assessment tool.
• http://www.certgear.com/products/preview/pmp_certification/index.html - Check out the bottom of the page for the download.
• http://www.pmstudy.com/enroll.asp - For this test, plan on taking a Saturday or Sunday Morning and sitting through the exam as if in a practice session.
• http://www.transcender.com/demos/#PMI - Trancender always has good test questions. Goes great with morning coffee.
• http://www.pmtests.com/packs.php - A free test is available for one day, so plan ahead and make the most of it.

Good Luck in your pursuits! If you are interested in reading a little further on project management, please check out:

• Twelve Rules for Project Management Success
• Quick Risk Management Checklist
• PMI's Earned Value Management Definitions and Formulas
• Anticlue's Project Management Wisdom

One of my favorite sayings is that bad news does not improve with age. This also holds true with identifying scope changes. I'm certain everyone has come across a scope change or two in your time. One truth of business is that scope change will occur. Another scarier concept is that your sponsor may not understand the costs of performing a scope change during analysis versus after unit testing. One of our responsibilities as good project managers is to make certain, the project team, sponsor, and stakeholders all understand the relative costs in identifying and performing scope changes sooner in the lifecycle rather than later. Hopefully, this will help why it is well work the planning time to firm up the discovery, analysis and detailed requirements and portray the value of a good scope understanding by all during planning. Further Readings

• The top ten causes of scope change
• That's just some mumbo jumbo project management BS!

In a mythical land - rain laden at this time - exists a beautiful historical community called Avondale. Avondale has seen its trials and tribulations over the years. Most houses were built before the great depression and have withstood hurricanes, tropical storms, and few ice storms here and there. Today we are going to focus on one particular house on winding way. The owner of this winding way home wanted her fireplace to work. It had been sealed since she bought the house some 20 years ago. So a year or two ago, she hired Jethro - a contractor to open up the sealed fireplace and make it a gas fireplace instead of wood burning. Jethro promised he could get the work done in a month and half. He proclaimed it was "no big deal", he had done this before. He could start tomorrow.

Our home owner was pleased, her request would be satisfied. In the late fall, she would sipping warmed cider by a warming fire. It was early May now.

Unfortunately as goes the tale with this contractor, there were some sudden items which popped up - here and there. The fireplace plugging took longer to remove than anticipated, apparently the gas line needed to be extend to the fireplace - this needed to be fixed. The nice remote control to turn on and off the gas fire was not clearly understood as being needed by Jethro. Time continued to slip by some days Jethro showed. Other days he was no where to be found. Maybe he suffered from the salt water flu - a common affliction of surfers in the Florida area - our homeowner mused. Come early September, our homeowner saw the finish touches about to be completed and was hopeful. All that was left was the inspection. Unfortunately, the 1921 Fireplace apparently needed to be hurricane proof, and it currently wasn't. Surprisingly to Jethro, the code had changed over the last 90 years. So throughout the month of October and a most of November, the fireplace was made hurricane proof. The homeowner watched her next years vacation funds going towards the hurricane-proof fireplace as she wondered why had they gotten here and how had so many things changed.

A couple of years went by and our homeowner decided to once again endeavor into home improvements. This time, she wanted to get the kitchen remodeled and replace the electric stove with a gas stove. She went with a new contractor Stan. Stan was the man. When our homeowner invited Stan into appraise the work, Stan took a couple of moments and explained how the process would work and the actual work with the kitchen remodeling and replacing the stove. They both agreed and then Stan said something different. "Let me share with you a little bit on how we are going to assure we understand the same things. I'm going to provide you with a binder notebook of what I understand we are looking to accomplish. I'll have one too. Yours will be here in a couple of days. I have a few things I want to check to make sure it is right. In a week or two, let's sit down together and review making sure we have everything right. You'll sign both copies, and I'll sign both copies. After we understand what is needed we can decide when to start. Along the way if something comes up or changes, just let me know. If I see anything I'll discuss it with you. We can evaluate the changes together looking at the implications and see if the juice is worth the squeeze. Then we will both sign the updated changes and add it to our books. This way at the end we will compare what's in our book to what was done. " Our homeowner was a bit hesitant as work wouldn't start right away, but was willing to try something new. She was suspicious of the time involvement this would take from her. She got the book a couple of days later, and there were some minor changes - it didn't take long to review about half an hour. A week later she and stan reviewed the book together and agreed to what was needed. During the construction, there were some changes here and there. Stan and her evaluated them together. All changes had reviewed the downstream effects to budget, resources, and schedule. Some where good suggestions for now, others were good for next years home improvement effort. When all was said and done, Stan and our homeowner compared the delivered work to what was in the books. Everyone was on the same page, and work had been delivered to schedule. If the change needed a schedule change, and it was an approved, then the schedule changed to accommodate it. Our homeowner reflected on the two construction efforts and realized taking the time to plan was good, but collaborating on suggested changes was what really made the experience pleasant.

What can we in Healthcare IT learn from this tale?

One of my favorite project management sayings is Good - Fast - Cheap you can have any two! Let's talk a little about a universal approach to having a good project scope change control process. Change requests have the power to change your deliverables, your team, and your budget, so it is essential to have a good process to manage these changes. When understanding how to approach a problem such as project scope change control, it is important to understand the causes of scope change.

The top ten causes of Scope Change are:

1. Business needs changed.


2. Business benefits changed.


3. Proper planning was not done.
   
4. Planning suffered a lack of stakeholder engagement.


5. Gold-Plating (scope inflation, scope creep).


6. Realized Risk


7. Project Resourcing Changes.


8. Project Funding Changes.


9. Project Schedule Changes.


10. A Corrective Action needs to occur

A point of note is that only one of the 10 relates to evil vile scope creep and scope inflation.

Interested in reading more on project scope? Further reading:

• Defining Project Scope


• Scope Planning

Let's talk a little about Lessons Learned. Lessons Learned are the key element to make your organization learn from items to assure your organization learns from the work of others. Lessons Learned are documented knowledge for continuous improvement. However, in order to fully utilize lessons learned, one needs to have check points in the PMI process.

The lifecycle with the key lessons learned inputs and outputs.

• Initiation - During the initiation phase, one should review similar projects in the past lessons learned. It will provide insight into resource needs, those opportunities and flags.


• Planning - During this phase, I recommend reviewing a lessons learned checklist. This document should have a little check point of what to exploit and watch out for throughout the project


• Executing - While executing it is a good idea to have a lessons learned log with key learning opportunities maintained. Provide an opportunity for key learnings at every other the project team meetings I try to offset the risk review with key learnings. One meeting agenda has risk review, the next week's agenda has key learnings.


• Monitoring and Controlling - All identified Key Learning opportunities should be reviewed as a part of monitoring and controlling. This is were you can immediately gain some benefit by incorporating a process that really worked out well or resolving a problem so it does not occur again.


• Closure - During closure one should go through the posts (Post Benefit Realization, Post Lessons Learned) It needs to be the PM's responsibility to assure that all captured items lessons learned log, post benefits, and post lessons learned

If your organization isn't practicing lessons learned yet, my advice is to plant a seed and watch it grow. Perhaps starting with the post project reviews is a good place or with the key learnings at the project team meetings. Grow both parts of that process until your organization looks ready for the next piece of the pie. I'd go for the checklist adds as a part of closure and reviewing the checklist as a part of planning. Pretty soon, the self-feeding lessons learned loop is just a part of the normal process.

In a new section here at Anticlue, every Friday we will be answering a reader's question. This week, our question is "What is the difference between the live plan and project plan?" from Cindy.

In PMI's strictest sense, the project plan normally refers to all of the project documentation from planning - the risk management plan, the communication plan, the procurement plan, the resource plan, ect.. However, commonly individuals refer to the project plan as the project schedule for example a microsoft project plan. This schedule commonly contains all of the work tasks for the entire project which are manageable for the project manager. I try to keep my tasks between 8 and 80 hours. This is mainly due to the fact during the implementation I find it is easiest to check up on work at this level. Therefore the project schedule has all of the tasks needed to implement the project.

One of my tasks is to develop a live-plan. The live plan is a checklist of all the activites which must occur for a successful live event. I also affectionately call the live plan the "chronolog". The chronolog is a checklist of all the approvals, tasks, validation items, and notifications for a live event. I've included a chronolog for an old SNA upgrade here. This document is developed by the team, the reviewed with the project sponsor, and affected department leadership. I commonly distribute the chronolog to the project team, leadership team, and sponsor team one last time before the event. It is helpful to keep everyone on the same page and know thier part for the live event.

Hopefully this helps to explain the difference! If you have any questions for reader question fridays, please feel free to ask. All questions are welcomed!

One of the many changes of a project management methodology is leaving the project chicken game behind and receiving accurate status reports. Perhaps you have never heard of project chicken, its an extremely frustrating game. You have a project team, all giving glorious fictional status reports of an on time and within budget project. Everyone is just waiting for someone else to relate they are behind schedule or have obstacles to prevent realizing the live event. But back to the topic at hand, obtaining an accurate project status from the team.

I'll recommend a couple of mechanisms. First is a check back, while in the team meeting after the assignment of the task. Place accountability on the individual performing the work to check back with you on status. Ask direct questions like "When would be a good time for you to provide a status?" Agree on a time, date, and formate, then include the outcome in the meeting minutes as an action item.

Some items require, your initiation for a check up. After assignment of the action item, it is clear you will need to check up on the status. In the team meeting, clearly identify when is a good time for the check up, and how it will be performed. Commonly, I mention items like "We are definitely going to need this {insert task here} completed by {insert deadline}. We are {how far away}. How about I call you to check up on the progress. Does {insert date and time} work for you?"

Another key item is to have issues addressed quickly. In meeting summarization after reiterating the assigned action items, it is wise to relay to the team if there are any concerns or yellow flags, to please let you know immediately.

Also if a task is taking a long time, break the task into key milestones for completion. This way you can measure progress. Another item is to ask for time spent during the week from your time reporting system.

Using these tips and trips, should assist you in obtaining an accurate status.

So as leaders, we need to survey the lay of the land, and not just the IT land. Often an organizational change is the successor to a "climatic" event trigger. Have you ever heard the saying a running ball in the road is often followed by a running child? How often do you stop your car when you see a running ball? That's the hard part, it is difficult to diagnosis the need for an organizational change before the event.

So let's discuss some key tactics around indicating that a PMO and dedicated discipline to project management is needed within your organization. Look and observe, are there any strategic projects being achieved? Do these projects have key warning signs of needing a rescue? Does the organization have a governance model which is extended to IT? Are the in-flight Active projects tied to specific business objectives? Another mechanism is to survey the organizations leadership. Asking key questions surrounding IT service, implementation practices, and especially capital planning processes. Have meetings with the key decision makers and IT's most significant customer. Who is IT's most significant customer, more importantly who is not. Analysis the response to the survey, do not just look for what you want to hear. Ask the question have you identified the right problem?

Another tidbit, is if you aren't hearing the complaints, the customers may just be so dissolutioned with your department they don't even care to complain.

A wise man once said, Project Management is doing project rights. Portfolio Management is doing the right mix of projects. Depending upon how your organization is utilizing information technology will be portrayed in your organization's project mix. Currently, we have a small project expense organization mix. Mostly upgrades and minor enhancements, some of it has to do with the economy and non-existent capital. Others can be viewed on how we have not yet achieved the term strategic business enabler. Some projects should be placed out into the pasture of long lost opportunities. Yet we continue to strive towards these endeavors.

Let's talk about some of the common characteristics displayed and when a project should be terminated.

• Lack of Sponsorship: Ever been on a project where the executive sponsor was walked to the door. Chances are the project should be halted and evaluated for re-engagement when the management renewal process comes to fruition


• Priority Changed: Its hard to keep the momentum on a project that jumps from critical to low to medium to low. Any degrade in priority should place the project on the murder board.


• Missed the target date: If you needed it by X, and it is now 30 days past X and it maybe another 60 days to get it done. Its time to decide if the moment of opportunity has past.


• Increased Risk: If in your risk management process, there is suddenly significant increased risk. It is time for the review of the kill criteria.


• Evil Vile uncontrolled Scope Creep: Do you have more scope changes than project tasks? Uncontrolled scope is just a project awaiting for the kill switch.


• Will not achieve benefits: If it doesn't have business benefits, don't do it. Could you imagine asking an organization to invest half a million in an upgrade, but still keep those life saving pharmacy rules turned off. If the project isn't going to realize the benefits, it is time to work on items which will.


• Severe Vendor Management Issues: Suffering from a vendor who no longer answers the phone, or perhaps the latest release has been missed. Be sure to review the dissolution terms in the contract, it may be time to execute those terms.

So if on your project dashboard, you notice 5 - 10 projects which should be killed what do you do? One suggestion is to have a project murder board, and for any of the poor performers have to have the sponsor justify the continued investment.

An easier item from a go-forward philosophy is to have project cancellation criteria right in the charter. It is easier to say based upon any of the above situations, that the project will be brought before governance for a value review. A part of this best practice to make the project manager accountable for triggering the review.

He who hath the money hath captivated the audience.

It has been a while since I posted. Too long in fact. So in considering what to share, I decided to discuss improvements to our project bulletin board. We have been diligently maintaining and distributing a project bulletin board for the last year. There are some lessons learned.

First, when drafting up the bulletin board, talk to your executives regarding the information to be shared. Assure there is a common understanding of the information and its relevancy.

Next, be certain to have a high level project budget numbers as a part of the reporting summarization. For example, knowing how much money has been spend to date, and the estimate to complete is valuable. It makes sense to include salary information for the individuals doing the project work also.

Another item to share is have a process or a way to clearly distinguish a project from a work order from a repeatable operational request. I've found as individuals struggle with the project concept, they substituted the define project management process to manage work intake for all work. It is unreasonable to create a business case for a software update which only entails updating the push package and testing it.

Have a review process of the status report, including the leadership team. Enlighten the project managers whose updates have been poor quality or non-existant on the consequences of their actions. It may take time to find a consequence which is concerning to the project manager.

Finally, beware of passive agressive resistance, some small recommended changes lead to significant reporting problems.

Begin with subjective criteria for spotlightening status. Have a formal plan to develop that criteria into clear objective criteria.

Remember, a yellow project highlighting risks may raise and continue to illustrate constant awareness.

Assure changes to the process after implementation are communicate at least eight different ways.

These are a couple of my lessons learned, I wanted to share. If you have had a similar experience, please feel free to share letting us know what worked and what didn't.

If you enjoyed this post, you may also want to check out:

• Implementing a project dashboard - Covers the format and the needed fields


• The Top 5 benefits to a project dashboard - Cover the business reasons for implementing a project dashboard


• Typical Barriers to Project Status Reporting - Covers the common resistance tactics to Status Reporting


• Is it yellow? May it is red? Sure it is not green - Covers the importance of establishing criteria for yellow, red, and green

Lately, I've been playing with a way to manage resource demand for upcoming project work. There are gaps or problems, which I believe are common place. I'll share them here for others.

First, even with the education provided, there is still a disconnect in the IT leadership minds as to what is project work and what is normal run and maintain work. Currently as a group we are walking through this distinction with normal run and maintain work versus project work. This is a problem area as it is difficult to quantify demand when one receives ongoing project resourcing. However, my discussing the issues, I am certain we can clear the haze.

Secondly, we have not been fully utilizing our time reporting system to quantify averages of where we place our time. One of the key constraints was the available reports, however we are working through this constraint. By the end of the month, we will have a good highlevel snap shot of our time spent in project work and run and maintain mode. While the past is not indicative of the future, this will provide a metric for planning purposes.

Finally, we are expanding on a format (probably in excel and access) to roll up our project demand for the upcoming months. This will place demand at a team level for upcoming project work. It has been illuminating to plan the next years plan with our current resourcing. We are highly overcommitted on the clinical side, as the demand for services are significantly higher than the resources available. Through our governance process and collaboration with the CNO, we should be able to move forward with the key endeavors.

A finding from this exercise, is the need to include resources for projects from the hospital and IT side in the project capital request. Not including the resourcing causes the resources to be pulled from operations, this lowers the quality of your operational support.

As we examine portfolio projects one of the key questions is did we launch the right mix of projects? Have we balanced our strategic initiatives with a smooth blend of operational endeavors with a smidgeon of mandatory requirements? One has to examine the portfolio from a holistic stance.

Normally, I like to breakout the demand into three groupings: capital, operational, and application support. Capital is the strategic demand, for capital requests are board approved endeavors and simply must be accomplished. Operational relates to departmental demand. These are the requests from the departments to automate business processes, and where a lot of the customizations, enhancements and variations to products are requested. Some refer to this as making a system sing, just be cautious on the time invested. Finally, there is the application support categorization. These are the routine demands to keep the systems running and up to date.

I've seem the gambit from currently striving for 100% strategic initiatives to 95% operational department requests. In my opinion your blend equates directly to the organizations usage of IT, is it a strategic enabler, or is it an operational expense of doing business. Typically, I refer to this gap between expense driven organization to a strategic enabler as the IT value chasm. Monitoring this metric is helpful to quickly identify the value of the IT organization. If you are crossing the it value chasm, the numbers should change in the direction of strategic enabler.

Let's take a couple of moments to talk about the fundamentals. A PMO needs to have some basic elements in place to drive the project portfolio. These elements include:

• A process for project presentation, prioritization, and selection.


• An understanding of budget and resource capacity of the organization.


• An understanding of the project demand


• The ability to measure and report upon project portfolio success.


• A continuous improvement process with metrics indicating the value of the improvement.

Without these key element, the PMO will end up like so many others after 3 years with no measurable way to indicate business value - Disbanded and disbursed.

Once of the key problems in today's environment of over meeting, is that it is very hard to get a group together within any reasonable amount of time. Key participants are normally booked or engaged in meetings ahead of time.

Therefore it becomes almost impossible to get the group together for decision making or problem solving. A practice we are starting to adopt is having a standing time, Tuesday Mornings 9 - 11 and Wednesday afternoons 1-4 for having Attendance Required Time Windows. All other meetings scheduled during these times are able to be cancelled or missed for the attendance of this meeting. It does help with project execution.

As with any change there are barriers, after rolling out a project bulletin board. I'd like to share the barriers, I have encountered and how to overcome these barriers.

First there is the avoidance barrier, expressed as either "This involves too much work" or "We don't have time for doing this." When hearing this mantra, I recommend a couple of tactics. First see if this is an education problem. Sometimes new project managers don't know how to do a project status report. Guiding them through a couple will help overcome the avoidance tactic. If that tactic is unsuccessful, explain that a project managers first and foremost job is communication, and if the project isn't worth communicating to our colleagues, then maybe it isn't worth doing. This is a little bit forceful, however it does overcome the avoidance tactic.

Second there is misperception barrier, commonly relayed in the "My project is different because ..." reasoning. This barrier arises due to a lack of understanding project management. One commonly heard form is "My project is different because we aren't managing it, the business is" Then when asked if it has a beginning and end, and it doesn't. It's time to ask if maybe we can get a scope of work around what we collectively are trying to accomplish. This barrier usually indicates the need to formalize the requested work.

Next there is the misunderstanding barrier, expressed as " This isn't a project it is a task." This barrier commonly arises when the Information Services organization is treated as an expense. Resources are consumed in task request work to help reduce the workload for clerk positions. Commonly to overcome this assumption the goal is to change perspective, look from about a skyscraper level as to what is trying to be accomplished. Normally there is a sense of purpose and business need with benefits to be realized. It just needs to be unvealed.

Finally there is the subversion barrier, commonly relayed as " I will just go to {insert over your paygrade title here} - he/she will see how this not useful" This barrier can be overcome by having a collaborative leadership team agreeing to the roll out for the standardized reporting. The standardized project reporting process brings transparency and clarity to the efforts of the IT organization. Other impacts may occur, but normally the clarity helps bring about the need for project work appropriately.

Here is a little checklist of what it means to do Risk Management during project management.

1. Use a risk-discovery process to compile the risks lurking about to impact the project
2. Make sure the entire core risks are represented on the risk register.
3. All risks should be analyzed and be reviewed with the following information:
• A risk title and a unique number
• An early realistic indication of the risk becoming real. In other words find all transition indicators.
• An estimate to the cost and schedule impact of the risk occurrence.
• Estimate of the probability the risk will occur
• A calculation for the risk exposure to the schedule and budget for the risk.
• What contingency plans can be put into action if and when the transition occurs.
• What mitigation actions can be taken in advance to make the desired contingency action is feasible.
4. Designate showstoppers as project assumptions. Please the assumptions on the risk register, negotiated the risk ownership to the appropriate management (this sometimes necessitates managing upwards)
5. Make a first pass at schedule estimation by assuming that no risks will materialize with the group of individuals responsible for the work. The goal here is to determine the nano-perscent date, the earliest date by which you can't yet prove to yourself that you won't be done.
6. Portray the uncertainty factions and use a monte carlo risk diagram with intersection at N.
7. Express all commitments using risk diagrams, explicitly showing the uncertainty associated with each projected date and budget.
8. Monitor all risks for materialization or expiration and execute contingency plans whenever materializations occur.
9. Keeps the risk management process going through out the project to cope with late-apparent risks.

As the development of a methodology persists for a PMO, there is a vagueness surrounding the conceptual differences between a project, program, and task. For the project description, simply having a temporary unique endeavor with a beginning and an end is almost too general and simplified. At times, I believe the disconcerting part is that the realization everything is a project comes to light. Projects are large, medium, small, and tiny. As clarification occurs, realization that the manual running of the report every day at 8:30 am really isn't a project, those additions of doctors to the doctor master, really isn't a project. In my experience, the difficulty embracing the concept derives from something deeper.

Organizationally, if you don't know what a project is at this day and age, then here is probably what is occurring in your HIT shop. First, there is no work approval or authorization mechanism for requesting work. Everyone probably has their own lists. Additionally, customization of the environment is spreading like a Californian wildfire sweeping through your ambulatory, clinical, revenue cycle, integration and financial systems. The inpatient billing manager says hey this would be easier and save me some clerk hours. The system analyst says sure, and adds it to her listing. All of a sudden, you have an outside billing interface controlling the system edits in a duplicative manner. Customization spreads. The problem with understanding the concept is not the concept itself. The problem is the realization, that most of the work your department engages in is pet projects for "preferred customers". The work doesn't relate to the strategic value of the organization, and conceptually you are investing your high quality talented resources in penny ante tasks. This is why the simple definition is a double edged sword.

As we struggle with this concept, comments like. "Well my work really isn't a project, it is just a bunch of tasks." Arise. To which my favorite response is, "Okay, well maybe we should group those tasks under a project or program. Can you tell me what benefits these tasks are bringing to fruition?" Afterwards, we continue the learning conversation.

The main purpose of a program is to deliver benefits which will help the organization realize its strategic objectives. Programs are strategy-oriented. Programs have a wide scope, so that the organization can change to meet the benefit expected. As a program begins to deliver the incremental benefits, these deliverables are often accomplished by projects. Obviously, within the project there are tasks to get the project completed and implement the deliverable.

A corporation's ability to plan their work and work their plan is the key difference between success and failure. If your enterprise doesn't understand the interdependent nature of departments, a component which can help bring a project in and deliver the benefits proposed is risk management.

There are areas of uncertainty to any project. Items to consider are:

1. Requirements: What exactly is needed to be done? What is desired? Where is the stretch goal?
2. Usability: How will the application interact with the end users?
3. Change Management: How will the business process be transformed after live? How will everyone be prepared for these changes?
4. Resources: What skills will be available as the project proceeds? What environments will be available as the project proceeds? Will the project sponsor be available?
5. Management: Will management be able to establish a productive team, maintain morale, minimize turnover and coordinate a complicated set of interdependent tasks.
6. Supply Chain: Will resources perform to the level as desired? Are the resources available? IS there a consultant contract in case such an item is unavailable? Is the procurement process understood and repeatable?
7. Politics: What political gambits and power plays will trump reality and impose constraints which place project success in jeopardy?
8. Conflict: How do members of a diverse stakeholder community resolve their individual (silo) goals when essentially the goals are incompatible.
9. Innovation: How will technologies and approaches unique to this project affect the outcome?
10. Scale: Have projects of this breadth and volume been successful based on past performance.
So as a starting point, I have a project today, which is an individual goal of our chief medical officer. We are going to walk through a risk discovery process reviewing the area's of uncertainty and identify all risks, ascertain our project's level of exposure to the risks, and develop contingency plans for those risks where warranted.

Surprisingly, it is simply amazing how essential the practice of risk management is in Healthcare IT projects and how often this practice is abandoned. As organizations mature and grow from a reactionary mode of operations to a proactive mode, risk management is often utilized in proactive organizations. However, when it is most needed in reactionary status, the organization isn't sophisticated enough to follow this practice.

For example, suppose you are a newly anointed project manager in an integrated delivery network, a local hospital system with a new practice structure. Project Management is a fledging practice. Organizationally, there is no work authorization practice. Requested Work is kept on individual lists for the application managers, (finance, revenue, clinical), application director, and the technology directors. Additionally the nuts and bolts of technology are outsourced, and technology managers (networking, telecom, desktop, client server) also have their own listing. Your morning visits to the local coffee shop are plagued with follow-ups in requests lost or misinterpreted on one of too many lists. The IT investment of the day goes to the business partner with the largest voice. Organizationally, the interpretation of the bottleneck is of not having project managers to manage the projects, not the lack of resources to do the projects. Often, project manager end up running the project, but also designing, constructing, testing, and deploying the solution. These considerations are constantly on your mind. After all, it's the technology investments of the organization you are responsible for delivering with your project sponsor.

You and the project team can easily manage some of the possible problems. These just need a quick tweak to a technical design or modification of workflow when the problem occurs. For example, there is no need to have an elaborate plan in place to add a field or two to an interface. Any technical pm worth their mustard should know how to handle that one and act accordingly.

However, it is obvious that there are graver risks, which are going to require some serious planning in advance. Resources being overloaded and pulled for other projects is such a risk. You should be aware that at any time, those who control the resources would pull the resources back to handle a fire, or support a higher priority project from their concern. In order to prevent such an occurrence, you need to do a significant amount of due diligence, including finding out other initiatives for resources needed for the critical path. Possibly even evaluating contract work for the integration work, and having the vendor solution analyst work with the sponsor as much as possible. There are many different routes to handle this risk although they all will require additional money.

The actual occurrence of a resource extraction will be invisible when it first happens. There aren't a lot of gates for the development of the interfaces, so you need to put in place and monitor some kind of control to highlight when a resource isn't dedicated to the project. You decide to note, that the team mates participation in the weekly meetings, and a stagnant status for a week are your indicators to enact an outside consultant. You choose to have the resources managers report status of the interface builds in a weekly review meeting. You also get outside estimates for how long a billing interface should take to build for a system with this level of customization.

Realizing resource extraction is only one of the risks requiring advanced forethought; you call a meeting with your project sponsor, executive sponsor, and key stakeholders. You review the potential problem with them, suggesting having a risk-discovery brainstorm, and develop a definitive list of potential problems, which need to be managed.

This is the ideal, however it is a good exercise to start the process of risk management. A risk is a potential problem. Once the risk occurs, it is not a problem. The point at which the risk materializes is the moment of risk transition. Once transition occurs, the project manager should act upon the plans to mitigate the risk. For every risk there is a transition indicator. For our risk above it is the lack of movement on the weekly status.

However, remember to educate and coach the organization. Persistants also helps to bring enlightenment.

Who makes the call, or whose decision is it? In healthcare information technology, there still continues to be a rift in some organizations between IT direction and Business Strategy. It is disconcerting when everyone is doing something unique in a silo. There is no re-use, customization rages across systems like a Californian wild fire, and knowledge resources become viewed as clerical resources. Most HIT structures are a federalize resource. There may be the Laboratory IS, Pharmacy IT, Clinical Engineering, Departmental System Administrators, IT department, and outsourced vendors. These many pieces and parts are needed to successfully implement projects. Nothing is a 30 minute job anymore.

Managing everything on a granular micro-managerial level is just not practical in today’s day and age. What does work? A governance structure.

Governance is about specifying who has the decision rights, and who should be accountable for the decision. A decision should not be made in a vacuum. The first step is to assure proper information or input is given to help the decision maker, by providing clarity to the problem and the advantages and disadvantages of different solutions.

What decisions are needed in IT? The book, IT Governance, clarified them quite well as indicated below:

IT Governance Decisions
IT Priniciples High level statement about how IT is used in the business
IT Architecture Organizing logic for data, applications, and infrastructure captured in a set of policies, relationships, and technical choices to achieve desired business and technical standardization and integration	IT Infrastructure Centrally coordinated, shared IT services which provide the foundations for the enterprise’s IT capability	IT Investment and Prioritization Decisions about how much and where to invest in IT including project approvals and justification techniques.
	Business application needs Specifying the business need for purchased or internally developed IT applications

As a leader of your department, if an IT governance process is not in place, or not functioning adequately take a minute to fill out where your are. Then in your opinion organizationally, where you think you should be. Interesting isn’t it? Now the question is how to lead the change to get there? Be sure it is aligned with the organization’s goals so the outcomes are desired.

IT Governance Arrangements
	Decisions
	IT Principles		IT Architecture		IT Infrastructure Strategies		Business Application Needs		IT Investment
	Input	Decision	Input	Decision	Input	Decision	Input	Decision	Input	Decision
Business Monarchy
IT Monarchy
Feudal
Federal
Duopoly
Anarchy
Unknown

 

Just in case you need it, there are the governance archetypes.

 

IT Governance Archetypes
Style	Who has decision or input rights?
Business Monarchy	A group of business executives or individual executives (CxOs). Includes council of senior business executives (may include CIO). Excludes executives acting independently
IT Monarchy	Individuals or groups of IT executives
Feudal	Business unit leaders, key process owners or their designees
Federal	C-level executives and business groups; may also include IT executives as additional participants.
IT Duopoly	IT executives and other group (IT liaison structure)
Anarchy	Each individual user

As I've previously stated, we are in the process of bringing up an IT governance council with the C suite of the Health System. This process of transforming the IT organization needs new skills and thought patterns. As we are currently in discussions with what process to use, and what criteria to prioritize against - the five pillars provided a good straw model for a dialogue with the execs. I can see these criteria beginning to align with the objectives of this year.

1. Bring up the new hospital
2. Make the financial numbers
3. Develop the strategic plan for the next three to five years

Simultaneously, we are working towards changing the attitude and culture of the IS department. Management engineering is hard but very rewarding work. We have developed a PM101 class here. The first class was a good start including the regional PM, and our CSC partners PMs. The team leads and PM's of the organization all agreed to the value of the concepts.

Another item we are starting is a project bulletin board. It basically contains for all projects, the basics - who, what, when, where, how and why. I'll share more on the bulletin board later as it is a good mechanism. Culturally to overcome the resistance, we are having a contest among the teams. The winning team is given chocolate from the losing team. (Managers buy the chocolate) We have increased steadily in the updates periods. (10 % to 33% to 55%) Hopefully this go round, we will have close to 100%.

Additionally we have set up a project governance council, including all the information services leadership including systems, technology, and our CSC vendor partner PMs. We review new processes, projects which have a red or yellow status, and new projects. For the bulletin board, now new projects must have a scope, charter, and schedule with committed resources before becoming active. In order for management to remove resources a scope change must be completed and approved.

For new requests, we have also implemented a work authorization system, with a short and long form. The short firm is a preliminary business case, and the long form has the ROI.

Things are changing, and the change is good. I'm concerned however in that the guiding coalition seems frail. As a team we will have to come together to move the organization forward, and put those petty differences aside.

"That's just some mumbo jumbo BS! Now, what's it gonna take to add sharepoint to our exchange implementation for the email file exchange size." I have to say, I almost burst out laughing, but it was coming from the project sponsor.

Here we sit with an groupwise to exchange migration. It's an old archaic version of groupwise. Organizationally we are migrating to exchange. This is the first recent attempt to come up with a project timeline and a scope. The technology engineers have been doing an excellent job to bring us to this point. We are in the testing, piloting, communicating, and training mode.

In the last two weeks, we started implementing some basic project management process. We are gathering the larger team including key stakeholders, marketing, education and development, and admins. We are beginning to communicate our intent, timeline, and gain understanding with the stakeholders. We even got an executive sponsor for the project.

We have implemented an issues log, instead of just going on and on about the problems at hand. Accountability and responsibility for resolving the issues are assigned. Also the resolution is recorded for future information.

We have implemented a scope change process, with a goal to present to executive leadership for funding requests, and prolonging the project.

We finally derived the first activity list which walked to the project schedule. Timeline for complete conversion and support is ambitious at about 3 months.

So what does one do, with the mumbo jumbo just getter done now statement? First off, I tried to ask question, about why it was needed. Then others pitched in understanding that this was just to derive an exception process. Finally, we will get the senior IS leadership team together to discuss the impact to schedule, funding and resourcing for adding in sharepoint. Also look for the team to do the scope change, not the project manager. The project manager should be able to present the scope change to senior leadership.

After the meeting, get some starbucks coffee, look at the beautiful storm surrounding the city and the effects on the river.

When you have a contract, the Contract Closure process is just common practice. Contract Closure puts the finishing touches on Project Procurement Management. The four inputs to the Contract Closure Process are:

• The Procurement Management Plan – The Procurement Management Plan is the play book for how to manage the Contract Closure process and to interweave it with other processes.
• The Contract Management Plan - The Contract Management Plan details how to manage the contract on significant purchases, throughout the life of the contract. A project team commonly refers to the Contract Management Plan for any contract closure guidelines surrounding a purchase. By providing information for the necessary documentation, delivery, and performance requirements, the team can assure the seller has met all obligations necessary for the contract to be closed.
• Contract Documentation - Contract documentation encompasses the contract, requested changes to the contract, approved changes to the contract, schedules, seller-developed technical documentation, and seller performance reports. Teams review contract documentation to ascertain what was in the contract originally and how that changed overtime. Additionally the team will use contract documentation to determine how the seller is reporting its performance. If the seller has met its agreed to obligations, then the contract can be brought to closure.

The contract closure procedure commonly occurs during the Close Project process. The contract closure procedure drives the process detailing all activities required by project team members, customers, and other stakeholders to settle and close any contract agreement established for the project, as well as define those associated activities supporting the project's official administrative closure. The contract closure procedure involves product verification and administrative closure. The contract terms and conditions can also appoint specifications for contract closure that must be included in this procedure. In project management, there are two common tools and techniques to close contract.

• Procurement Audits - A procurement audit consists of a structured analysis of the procurement process from the Plan Purchases and Acquisitions process through Contract Administration. Procurement audits identify successes and failures that project managers should take note of when preparing or administering other procurement contracts for the project or other projects within the performing organization. The audits bring successful practices to light which can be used in the future. Additionally, procurement audits identify any related project failures during procurement processes which can be avoided in upcoming projects. The procurement audit includes examining activities related to requirements definition, tendering, bid evaluation, contract award, contract examination, and contract closure.
• The Records Management System – The records management system is a set of processes, related control functions, and automation tools that are condensed as part of the project management information system. Project managers use a records management system to manage contract documentation and records. The organized system helps index and store contract documentation, records, and correspondence created during contract closure. It also assists with archiving project procurement documentation associated with contract closure so project managers can retrieve it in the future.

Procurement audits and records management systems are the two tools for the Contract Closure process. Procurement audits are used to identify project successes and failures so that best practice is ensured when contracting. Records management systems are used to manage documentation and records related to contract closure. The system helps with maintaining an index of contract documents and correspondence, and archiving and retrieving that documentation. After you have done the due diligence the out puts of the Contract Closure process are:

• Closed Contracts - Closed contracts provide formal notification to assure everyone agrees that the deliverables have been successfully achieved and that the contract has been closed. It is the project manager’s responsibility to ensures that each seller receives a formal notification of completion. Closed contracts are also used is to provide documentation in the case of unresolved disputes. Future unresolved claims could arise, related to contract closure and conditions, that are subject to litigation. To be prepared for this possibility, make sure that all closed contracts are filed and kept in order.
• Organizational Process Assets (Updates) - Updates to organizational process assets are the second output of the Contract Closure process. They consist of a set of documentation that includes the closed contract, the buyer's official notice of acceptance or rejection of the deliverables, and recommendations from project experience to use in future projects. The project manager puts project documentation in the contract file and stores it for future accessibility. The project manager may need to refer to the contract file later for litigation purposes and to review prices if there are ongoing pricing contracts for provision of products or services. Check with local and state authorities for specific record retention requirements before destroying any documents.

We in the industry all know, there is a plethora of reasons for initiating a project. Before we had a structured request method for project at one place, several ITers never lunched in he cafeteria because it just created a long streaming request pool of which was unprioritized. So let's discuss structured decision criteria aligned with strategic directives. According to PMI, organizations typically have 6 prime reasons for initiating a project:

• Market Demand


• Business Need


• Customer Request


• Technological Advance


• Legal Requirement


• Social Need

I think it would be an interesting exercise to relate these needs to the five pillars of healthcare: Services, People, Financial, Growth, and Quality. As sometimes technology is necessary to be in existence, I'd like to suggest agreeming upon an infrastructure category. For example, having smart infusion pumps require an 802.11 wireless network, but not an RFID functionality (if the tracking is being offered via 802.11, sometimes the RFID component of this just doesn’t pay for itself) So a wireless network is a required technology building block for a smart infusion pumps deployment.

An example of decision criteria with semi-fictious descriptions and examples.

Decision Criteria	Descriptions and Examples
Services
Improve Patient Satisfaction	~ Improves Responsiveness to Patient’s Needs ~ Improves Convenience for Appointments and Procedures
Improve Clinical Outcomes	~ Improve Quality of Care and Patient Safety (Reduce Medical Error Rates
Improves Community Relations and Outreach	~ Improves referrals from community physicians.
People
Physician Relations & Satisfaction	~ Improves access to online information at the point of care
Employee Satisfaction	~ Attract, recruit & retain high-performing workforce ~ Improve management controls of overtime and shift placement
Financial
Enhances Operational Efficiency	~ Turn around Times are reduced. ~ Patient Flow is Optimized. ~ Standardize Hospital Information System to reduce costs
Strong Return on Investment	~ Payback Period within five years ~ Internal Rate of Return at 12%.
Growth
Improves Market Share	~ Support new/enhanced clinical strategies (Cardiology, Stroke Center, Orthopedics)
Improves Competitive Advantage	~ Assures Inpatient, Outpatient, Rehab, and Long Term Care Growth
Quality and Patient Safety
Align with Regulatory Requirements	~ Project directly supports regulatory compliance, e.g. JACHO, HIPAA, OIG Guidelines, CMS guidelines, HEDIS guidelines, UNOS Reporting.
Process Improvement	~ Six Sigma Process Improvement Projects
Addresses Significant Deficiencies	~ Adverse Events are proactively detected and averted in a timely manner.
Infrastructure
Technology Building Block	~ Supports enhancing the exchange of information ~ Supports future technology additions.
Required Application Maintenance	~ Application has been retired.
Provides Essential Infrastructure	~ Moves from Microsoft and Novell to Linux

Aligning this with PMI standards would be as follows:

Decision Criteria	Descriptions and Examples
Market Need
Improves Market Share	~ Support new/enhanced clinical strategies (Cardiology, Stroke Center, Orthopedics)
Improves Competitive Advantage	~ Assures Inpatient, Outpatient, Rehab, and Long Term Care Growth
Business Need
Physician Relations & Satisfaction	~ Improves access to online information at the point of care
Improve Patient Satisfaction	~ Improves Responsiveness to Patient’s Needs ~ Improves Convenience for Appointments and Procedures
Improve Clinical Outcomes	~ Improve Quality of Care and Patient Safety (Reduce Medical Error Rates
Strong Return on Investment	~ Payback Period within five years ~ Internal Rate of Return at 12%.
Customer Request
Process Improvement	~ Six Sigma Process Improvement Projects
Addresses Significant Deficiencies	~ Adverse Events are proactively detected and averted in a timely manner.
Enhances Operational Efficiency	~ Turn around Times are reduced. ~ Patient Flow is Optimized. ~ Standardize Hospital Information System to reduce costs
Employee Satisfaction	~ Attract, recruit & retain high-performing workforce ~ Improve management controls of overtime and shift placement
Technology Advancement
Technology Building Block	~ Supports enhancing the exchange of information ~ Supports future technology additions.
Required Application Maintenance	~ Application has been retired.
Provides Essential Infrastructure	~ Moves from Microsoft and Novell to Linux
Legal Requirement
Align with Regulatory Requirements	~ Project directly supports regulatory compliance, e.g. JACHO, HIPAA, OIG Guidelines, CMS guidelines, HEDIS guidelines, UNOS reporting
Social Need
Improves Community Relations and Outreach	~ Improves referrals from community physicians.

So what was the purpose of this exercise? The 6 prime reasons for initiating a project can be used as a part of project selection criteria, and again aligned with the strategic relevance. Although I strongly recommend having the discussion of strategic goals and cascading those throughout the decision criteria. The important point is that the decision criteria must be applicable across the project request pool and without exception before project selection. This standardizes the process and implements a best practice.

Started rolling out the prioritization criteria for the project in the Liaison meetings this week, overall it was a good start. I have a couple liaison meeting responsibilities -Radiation Oncology and Cardiology. Items I’ve learned from past experiences, is that honesty is the best policy, and honest communication is necessary.

First, we discussed the structure and roles of the organization and reviewed the new process.

All project requests coming into IS will be via a standard form to be posted on the intranet. They will need to be agreed to by the project sponsor and executive sponsor upon submission.

Here is a sample of our current project request form:

Information Services Project Request Template
Project Name:
Project Sponsor:
Executive Sponsor:
Date of Request:
BUSINESS OBJECTIVE
INITIATIVE SUMMARY
STRATEGIC RANKING OF PROJECT REQUEST
STRATEGIC RELEVANCE																					SPONSOR SCORE
ENHANCE PATIENT SATISFACTION																			SERVICES		{ 0 - 10}
IMPROVES CLINICAL OUTCOMES																					{ 0 - 10}
IMPROVES COMMUNITY RELATIONS AND OUTREACH																					{ 0 - 10}
IMPROVES PHYSICIAN RELATIONS & SATISFACTION																			PEOPLE		{ 0 - 10}
IMPROVES EMPLOYEE SATISFACTION																					{ 0 - 10}
ENHANCES OPERATIONAL EFFICIENCY																			FINANCIAL		{ 0 - 10}
STRONG RETURN ON INVESTMENT																					{ 0 - 10}
IMPROVES MARKET SHARE																			GROWTH		{ 0 - 10}
IMPROVES COMPETITIVE ADVANTAGE																					{ 0 - 10}
ALIGNS WITH REGULATORY REQUIREMENTS																			QUALITY AND PATIENT SAFETY		{ 0 - 10}
PROCESS IMPROVEMENTS																					{ 0 - 10}
ADDRESSES SIGNIFICANT DEFICIENCIES																					{ 0 - 10}
TECHNOLOGY BUILDING BLOCK																			INFRASTRUCTURE		{ 0 - 10}
REQUIRED APPLICATION MAINTENANCE																					{ 0 - 10}
PROVIDES ESSENTIAL INFRASTRUCTURE																					{ 0 - 10}
STRATEGIC RELEVANCE
BENEFITS REALIZATION PLAN
BENEFIT				GOAL / OUTCOME						TIMELINE					RESPONSIBLE						METRICS FOR SUCCESS
PRELIMINARY COST AND TIMING
PROCESS IMPACTED

The key point is as a part of the request process to have a strong understanding of business need, and how success will be measured as a part of the request. To link the tactical requests to strategic planning, we have the current decision criteria. As the process matures, this criteria is linked to our strategic goals. The section on strategic relevance is an opportunity to articulate the decisions behind the ratings. I’m currently finishing up a guideline on a baseline of the criteria. The benefits realization plan is a way to clearly identify the improvements being offered by our solution.

The next key activity was to review our prioritization criteria and walk through the exercise of prioritizing our current work. A couple of questions and outcomes arose, which were insightful and I’d like to share.
Question: What happens if the strongest departmental request is not rated higher than the others?
Answer: Based upon the rating scale and weighting, we should be in good shape. Let’s walk through that request. The key in this request was it had the required application maintenance, and technology building block criteria.

Question: What number do we need to reach to assure this gets done?
Answer: Honestly, I don’t know. We have to establish a well founded decision which can be supported when asked by our executive leadership. If the project is simply not rated with enough priority, I’ll be happy to work with you to present it to our evaluation council (murder board) to help gain resources for the project.

Organizational change is the fine art of explaining the sense of urgency, sharing the vision of the future, listening to other’s concerns, and engaging in a dialogue which fosters a shared understanding. The good news was with this customer base, we have successfully started the process.

Oh, I think I need a project murder board. For those of you who aren't familar, a murder board is a group of individuals from key business constituents who decide whether a project cuts the mustard or doesn't. Organizationally, I'd like to have a such group in place, but let me share a little history.

First, this is a new gig for me, and I really enjoy it. It is a great place to work with a good work-life balance. I've been challenged with implementing a project management office. To start with we have more projects than can be reasonably completed by the amount staff we have in place. We could grow to more staff, but currently a majority of the project work is individual department requests. There are more than a few capital initiatives which are aligned with strategic goals.

I've derived a centralized project listing to replace everyone's individual list and categorized the project work as active, inactive, requested, completed/cancelled. We had a good sized listing of active project work, about twice the amount we can complete with our staffing model today. I can see we are at the project log jam in the river, with stealing peter to pay paul from a resourcing perspective.

Our next step is as a leadership team, to gather several categories of which to prioritize project against. We decided on a good set of criteria based upon the five pillars of healthcare - Service, Financial, Growth, People, Quality and Safety. For good measure we have added a technology category to position needed items for technology building blocks. Currently we are engaged with our customers of prioritizing all active work according to the criteria.

Simultaneous, we are starting an Investment Council for Information Technology (IC IT). This council is comprised of the senior leaders of the institution making the decisions for which capital projects to invest within and the timing of that investment. Right now, we are in the politicing and gathering stage, but it is a key factor to our success. Assuring the right and accurate information is in the hands of the decision makers, with proposed business cases having all the resourcing and justification from the technology and business partners. It just sets up the organization for successful implementations.

As we go through this process, there will be the outliers, the pet project. Here is where the project murder board comprised of a few key executives would help. Here is where project sponsor's would have a place to present their concerns if their project doesn't rate above the line. The decision to resource would need to be at this level if the project passed the boards inquiry.

Althought I'm wondering if there are any other techniques individuals have tried... All suggestions are welcomed.

The Contract Administration process helps to assure the project’s goals and needs are on track and on schedule and the seller is behaving appropriately. The Contract Administration process is apart of the Monitoring and Controlling Process Group. The inputs for this process are:

• Contract - A contract is an agreement between the buyer and the seller which details their legal requirements and obligations.


• Contract Management Plan - The Contract Management Plan utilizes the existing contract requirements to provide the buyer and the seller with guidelines for administering and monitoring contracts for significant purchases or acquisitions.


• Selected Sellers - The selected sellers are sellers that the buyer deems the best candidates for the project and that have negotiated a draft contract.


• Performance Reports - Performance reports are more detailed than work performance information, they use methods such as bar charts and S-curves to organize and summarize information such as earned value management and project work progress.


• Approved Change Requests - Approved change requests verify which changes to contracts or procurement procedures have been processed and approved.


• Work Performance Information - Work performance information, which comes from the Direct and Manage Project Execution process, provides statuses of the project schedule activities being done to accomplish the project work. The team uses it to monitor the sellers' progress on schedule, deliverables, and costs.

Once you have been able to get through the selection/acquisition phase, the project manager needs to track administrative issues, contract changes, and the seller's progress and quality of work to assure that the project is running smoothly. The tools and techniques for the Contract Administration process are:

• Contract Change Control System - A contract change control system defines the procedures for changing a contract. It encompasses all forms, documented communications, tracking systems, and dispute resolution procedures. Additionally approval levels are necessary to authorize changes and the procedures for getting the changes approved within the performing organization. The contract change control system should be integrated into the Integrated Change Control System.


• Buyer-conducted Performance Review - A buyer-conducted performance review tracks the vendor’s progress in execution and product delivery within contractual parameters. Hopefully, your organization is including the cost and project schedule in the contract. The purpose is to manage contract performance by recognizing performance success and failures, anticipated completion on the contract statement of work, and finally identify areas of contract non-compliance.


• Inspections and Audits - Inspections and audits identify any defects in the delivered work or product. Project managers assure inspections are conducted and audits occur with the live event of a new process or inspect new procedures.


• Performance Reporting - Performance reporting involves gathering the vendor’s performance data and distributing it to stakeholders. Performance Reporting can help to alert management on whether the vendor is meeting contractual objectives.


• Payment System - Payment systems are tools and claims administration processes used for Contract Administration. The buyer uses a payment system to compensate the vendor according to contract terms. Payment systems include project management teams' reviews and approvals. Larger projects may have individual payment systems.


• Claims Administration - Claims administration resolves claims according to the contract's dispute resolution procedures when the buyer and seller cannot resolve a claim on their own. Claims administration documents, processes, monitors, and manages claims during the life of the contract, usually according to the contract terms.


• Records Management System - A records management system is a set of processes, related control functions, and automation tools which are used to manage contract documentation and records. Project managers use records management systems to manage contract documentation and records; to keep an index of contract documents and correspondence; and for help with retrieving, accessing, and archiving that documentation.


• Information Technology - Information technology makes contract administration more effective by providing electronic data exchange between the buyer and seller, and automating portions of certain systems and processes. Using information technology automates parts of the records management system, payment system, claims administration, or performance reporting.

The Contract Administration process outputs are:

• Contract Documentation - Contract documentation includes the contract, schedules, requested unapproved contract changes, approved change requests, any seller-developed technical documentation, and work performance information.
  
• Requested Changes - Requested changes to the Project Management Plan, its subordinate plans, and other elements—such as the project schedule and Procurement Management Plan—may occur due to the Contract Administration process. They are submitted for approval to the Integrated Change Control process. Normally requested changes are addendums to contracts.


• Recommended Corrective Actions - Recommended corrective actions are measures to make the seller compliant with the terms of the contract, such as sending a warning letter requesting resolution of the problem or withholding payment until the problem is corrected.


• Organizational Process Assets (Updates) - Updates to organizational process assets consist of the buyers' and vendors' written records of all contract administration, including actions taken and decisions made, results of buyer audits and inspections, payment schedule updates, and seller performance evaluation documentation.


• Project Management Plan (Updates) - Updates to the Project Management Plan will consist of approved change requests affecting the Procurement Management Plan.

That’s the ITTO’s of the Contract Administration Process.

The select sellers process is used to evaluate the vendor proposals by applying the evaluation criteria to ascertain who makes the cut and who doesn’t. So the selection process consists of gathering all proposals, evaluating the proposals (against criteria not other proposals), and finally contracting with the seller.
So what do you need before you begin the process? Here are the inputs to the select sellers process.

• Organizational Process Assets – The organization process asset we are specifically referring to are the formal policies which impact how a proposal is evaluated.


• Procurement Management Plan – The procurement management plan is used because it describes the complete procurement process from development to contract closure.


• Evaluation Criteria - The evaluation criteria was developed for the expressed purpose of rating proposals. So now is the ideal time to use this document.


• Procurement Document Package – The procurement document package is the guide which you provided to the vendor so the vendor could appropriately respond and submit the proposal.


• Proposals – The proposal is the vendor’s written response to the request.


• Qualified Sellers List – The Qualified Sellers List contains the list of sellers who were approved to participate in the bidding process.


• Project Management Plan – The Project Management plan has the risk register and risk-related contractual agreements. These documents will be used within the selection process.

These inputs will allow the project team to make a reasonable, informed decision. The next step is going about making the decision for the best candidate. Thankfully once again we have some best practice guidelines to follow. The recommended tools and techniques for the select sellers process are:

• Weighting Systems – The Weighting systems are employed to quantify personal perspectives. To use a weighting system, assign a ranked weight to each of the evaluation crieteria. Next, rate the vendor on each criteria, multiply by the weight, and total the result for the overall score.


• Independent Estimates – Independent Estimates depict the intended costs of the project. This is basically a check and balance technique. It can be done in house or with an independent consultant.


• Screening Systems – Screening is a pass/fail method for certain criteria deemed essential for project success. For example, if you are implementing an Ambulatory EMR is e-prescribing a vital component?


• Contract Negotiations – Contract Negotiation is the process of coming to a mutual agreement regarding terms and conditions.


• Seller Rating Systems – Seller Rating systems rates sellers upon past performance commonly reviewing quality, delivery performance, and contractual compliance.


• Expert Judgment – Expert Judgment is used to have a multi-discipline team evaluate the vendor’s proposal.


• Proposal Evaluation Techniques – Proposal Evaluation Techniques is a combination of the above – most commonly expert judgment and evaluation criteria.

After using the above tools and techniques, you should be able to generate the outputs of the select sellers process. Those outputs are:

• Selected Sellers – The selected sellers are vendors who have chosen.


• Contract – The contract is the agreement between the buyer and the seller documenting the master service agreement, breakage terms, addendums, statement of work, specifications and price.


• Contract Management Plan – The contract management plan details how to manage a major purchase. Sometime details payment arrangements, performance requirements and documentation delivery.


• Resource Availability – Resource availability state the quantity and availability of resources, along with documented dates of when the resource is active or idle.


• Updates to the Procurement Management Plan – Updates of any approved change affecting procurement management.


• Requested Changes – Certain changes to the plan should be processed through integrated change control.

The Request Seller Responses process is when the project manager obtains the quotations, bids and proposals from the vendor. The vendor responses should include how the project requirements can be reached and the costs associated. Just remember there needs to be time for the vendors to generate proposals.

The inputs into the process are:

• Organizational Process Assets – Organizational process assets normally have a list of bidders. For example if one is moving into WOW (workstations on wheels), having a group of vendors listing who have been successful in the organization is key. Once I was going through a pilot, and our COW vendor never delivered the hanging file folders for the ED WOWs. After escalating the issue with the company, the guy showed up with wire ties and metal folders from staples. Needless to say, this vendor was not on the house wide roll out.


• Procurement Management Plan – The Procurement Management Plan details how to manage the procurement. It is good to refer to this and inform the prospective vendors of your internal process.


• Procurement Documents - Procurement documents are from the Plan Contracting process which describe how the seller's response should be presented, provide details about the required product, service, or result. Basically these are a guideline for bids or proposals to your organization.

When obtaining bids from vendors it is a key point to keep in mind, one has to ask for the right information in the right way. Otherwise as a project manager, you may be tagged with favoritism.
So how does one create a sandbox for all vendors to play in and not get into sand ball wars? The tools and techniques recommended from PMI are:

• Bidder Conferences - Bidder conferences are a meeting with all the potential sellers to assure requirements are clear for the project and the bidding process. These are particularly useful for complex, technical, or flexible procurement specifications because they provide a forum for discussion with everyone. An outcome of a bidder conference maybe to change the procurement documentation in order to reflect what sellers are capable of delivering.


• Advertising - Advertising is used to increase the potential seller list by publicly stating the solicitation in magazines, newspapers and other publications.


• Develop a Qualified Sellers List - By working from organizational supplier lists, trade organizations (like himss), or trade magazines, the project manager can determine whether potential sellers are qualified to deliver the product, service, or result required.

Requesting Seller Responses will help assure willing capable sellers are approached for a proposal.
At the end of the Request Seller Responses process, you should have the following outputs:

• Qualified Sellers List - The Qualified Sellers List is a list of vendors who are being asked to submit a proposal.


• Procurement Document Package - The Procurement Document Package is instructions for how the vendor is to respond to the proposal.


• Proposals - Proposals are seller prepared response which details how the seller will deliver the required product, service, or result. Proposals are considered a formal and legal response to the buyer’s request. Sometimes these are followed by on-site vendor presentations.

Plan Contracting provides the time and place to craft the documents needed to support the Request Seller Response process and Select Sellers process. The Plan Contracting process provides the documents which enable requesting seller bids and determining which sellers to move forward with through the contracting phase.

As with most process, there are input needed to assure all necessary information is in place for a decision to be made. The inputs to Plan Contracting are:

• Procurement Management Plan - The Procurement Management Plan details how the procurement process will be managed. It covers all aspects from procurement documentation to contract closure. As a part of plan contracting, check out the components which detail contracting requirements, what type of information is to be shared with a seller, and what is the process for managing the contracts. Also take a long look for any pre-approved sellers, and what type of contracts which can be utilized.


• Contract Statement of Work (SOW) - The Contract Statement of Work (SOW) provides a very detailed description regarding the product, service, or result to be delivered under contract. Honestly in my experience, spend a lot of time here gathering the requirements and needs. Run it by all members of the decision making team to assure everything is captured before using it. The Contract Statement of Work should deadlines and product specifications. In addition it should have any service requirements, quality information, performance data and anything else relevant. Performance data is key, this has bitten me before with several of our purchased customized solutions.


• Make-or-buy Decisions - The make-or-buy decisions are a documented decision list of the items to be purchased and those items to be produced by the project team. The make-or-buy decisions are reviewed as the basis for knowing what will be contracted to external sellers.


• Project Management Plan – The Project Management Plan should be reviewed with a focus on scheduled delivery dates as the procurement documentation should be in line with those dates. Additionally check out the risk register for risk related contractual agreements. The risk related contractual agreements detail agreements for insurance, services, or other items which list each parties responsibility.

The Plan Contracting process is a review of what is to be purchased and acquired, and how to create the information for potential sellers to assure all requirements have been met.
Hopefully your organization has a standard process for preparing this documentation. If not quickly establish one. There are two tools and techniques used in the plan contracting process.

• Standard Forms - Organizations often create standard forms for use when choosing and working with sellers to ensure that documentation is consistent and meets organizational requirements. Standard forms can include:
  
  
  • Standard contracts – One common tactic my last employer used was having a master service agreement and all procured services as an addendum to that core contract.
  
  
  • Standardized descriptions of items to be acquired
  
  
  • Nondisclosure Agreements
  
  
  • Checklists for evaluation of proposals or bids
  
  
  • Templates for each required element of the procurement documentation.


• Expert Judgment – Expert Judgment should be used to verify and validate that the most informative information is provided to the seller. Have different experts can check for the correct use of technical jargon, legal issues, or areas where best practice or industry standards could be used.

Using standard forms and expert judgment allows project managers to have a systematic approach for developing information for sellers. Quality documentation goes a long way towards assuring the organization gets what it wants when it needs it.

After the completion of plan contracting, one should be able to provide potential sellers with the information they need to bid, tender, quote, or make proposals, use agreed-on criteria to assess the bids, tenders, quotes, and proposals supplied by potential sellers, and ensure that the work specified or requested accurately represents the needs required. This information is commonly found in the outputs of plan contracting.

• Procurement Documents - Procurement documents are used to seek bids, tenders, quotations, or proposals from prospective sellers. Procurement documents are prepared in accordance with the buyer's organizational requirements and usually include a description of how the seller should respond, the relevant Contract Statement of Work, and any contractual requirements. The documents should be comprehensive enough to allow sellers to provide a clear proposal or a quotation, but also provide flexibility for sellers to suggest new or adapted approaches where appropriate.


• Evaluation Criteria - Evaluation criteria are developed to rate or score proposals. Notice, this is done before any proposals are received. The criteria will be both objective and subjective. The criteria are often included within the procurement documents to allow sellers to ensure that they provide all of the information required by the buyer to make a decision. Some common evaluation criteria examples are:
  
  
  • Understanding of the need – How well does the seller address the contract statement of work?
  
  
  • Overall or life-cycle cost – Purchase plus operating cost
  
  
  • Technical Capability – The seller is expected to have or acquire the needed technical skills and knowledge
  
  
  • Production capacity and interest – The seller has the capacity to meet potential future requirements.
  
  
  • Business size and type
  
  
  • References
  
  
  • Intellectual Property Rights
  
  
  • Proprietary rights


• Contract Statement of Work (Updates) - The Contract Statement of Work describes the product or service to be acquired in enough detail to allow prospective sellers to determine if they are capable of providing it. During the Plan Contracting process, expert judgment and other considerations made during the development of documentation can result in modifications being made.

An interesting high level comparison of PM methodologies can be found here.

The Plan Purchases and Acquisition process provides a pattern which can be used to determine which needs are better met by using an outside organization versus the project team. Common inputs to this decision is when the result is needed and how best to obtain the result.

As with all processes, there are inputs to the Plan Purchases and Acquisitions Process. These inputs provide the foundation for determining what, when, and how to purchase. These input are:

• Enterprise Environmental Factors – Enterprise environmental factors concerning mark conditions. What products, services, and results are available in the marketplace? Where can you obtain them? Are there terms and conditions which are applicable? Is there a legal or purchasing department? Or is that the project teams responsibility?


• Organizational Process Assets – Organizational process assets depicts whether formal or informal policies and procedures exist for dealing with procurement within the organization. Some common types of organizational process assets are, all requisitions for purchase orders must be signed by the CIO. All purchase requisitions above $2000 must be initialed by all EVPs. All vendors must have been in business for a period of at least 3 years.


• Project Scope Statement – Project Scope Statement details the projects boundaries, requirements, constraints, and assumptions. Check out the constraints in the project scope statement to see if there are any required delivery dates or need for skilled resources.


• Work Breakdown Structure – The Work Breakdown structure illustrates how each work package’s interdependencies.


• WBS Dictionary – The WBS Dictionary details the work needed to complete each WBS package. Check out the contract info and quality needs when reviewing for the planning and acquisition process.


• Project Management Plan – The project management plan is the plan for managing the project. With the plan purchases and acquisition process check out the following items:
  
  
  • Risk Register
  
  
  • Risk-related contractual agreements
  
  
  • Activity resource requirements
  
  
  • Project Schedule
  
  
  • Activity Cost Estimates
  
  
  • Cost Baseline
  
  

When it is obvious that there may be a need to buy products, services, or results, one should be able to articulate what is needed, when, and all other concerns. Some common tools and techniques used to help articulate what is needed, when, and how are:

• Make-or-buy Decisions - Make-or-buy analysis involves comparing the relative benefits of in-house versus out-sourcing production of a given product, service, or result. Common considers are if the skill set in house is capable of delivering the product or service and if the same quality or a higher standard can be obtained from outside.


• Expert Judgment - Expert judgment brings in specialized advice, such as technical, legal, or market knowledge, to inform buying decisions. Sometimes using experts can bring about new approaches which simply were not considered without the expertise or experience of being one that has already been there done that.


• Contract Types - Contract Types are the types of contracts available for use. Different contracts are used for different purposes and intents. Generally there are three main categories:
  
  
  • Fixed-price or lump-sum contracts – Generally involves a total price for a wel-defined product. Fixed-price contracts may include incentives for early delivery. Buying shrink wrapped software is commonly a fixed price contract.
  
  
  • Cost-reimbursable contracts – Generally involves payment to the vendor for actual cost plus a fee for profit. Actual costs comprise direct and indirect cost of making the product or providing the service. There are three common types of cost-reimbursable contracts.
    
    
    • Cost-Plus-Fee (CPF) or Cost-Plus-Percentage of Cost (CPPC) – In this type, the seller is reimburse for the allowable costs and receives a percentage of the costs as a fee.
    
    
    • Cost-Plus-Fixed-Fee (CPFF) – For this type, the vendor is reimbursed for allowable costs and receives a fixed fee. The fee normally doesn’t change unless scope changes allocate a new fee.
    
    
    • Cost-Plus-Incentive-Fee (CPIF) – Cost-Plus-Incentive reimburse the seller for allowable costs and allocates a predetermined fee, as an incentive for achieving certain performance objectives.
    
    
  
  
  • Time and Material contracts – T&M contracts are a hybrid combination of cost-reimbursable and fix price contracts. A common indicator is their open-ended nature. The full value of the agreement and the exact quantity of items to be delivered are not defined at the time of contract award.
  
  

When purchasing solutions, it is important to assure that the best choice for the organization has been chosen and it is what was required. These tools and techniques offer a way to assure needs are defined and met. The outputs to the Plan Purchases and Acquisitions process are:

• Procurement Management Plan – The procurement management plan explains how procurement will be managed from inception to closing. Commonly the procurement management plan details the types of contracts to be used, who is accountable for estimates, the guidelines for the build or buy decision. What are the common lead times and how best to handle them? Finally what is the form and format of the statement of work?


• Contract Statement of Work (SOW) - The contract statement of work explains the items being purchased with enough detail and clarifications for everyone to be in agreement with what is being purchased. The contract statement of work should have a clear concise description of the services needed and operational support.


• Make-or-buy Decisions – Make or buy decisions are pretty self explanatory as to the purpose. However, it is good to have a document with a list of the justification for the decision and responsible party.


• Requested Changes – Requested changes to the plan should be placed into the integrated change control process.

Project Procurement Management involves engaging in a systematic process to purchase or acquire the needed products, services, or results from an outside source which will perform the work. Procure Management encompasses contract management and control processes necessary to administer contracts or purchase orders. It also includes processes which assist in administering a contract to assure the buyer/seller relationships are properly managed. The procurement management processes are:

• Plan Purchases and Acquisitions – Plan Purchases and Acquisitions process involves ascertaining what is needed, and when it is needed. Then how to assure you have what you need when you need it. (Novel concept!) This is completed as a part of the planning process group.


• Plan Contracting – The Plan Contracting process involves documenting the products, services, and results requirements and identifies potential sellers. Plan Contracting is commonly first engaged in the planning process group.


• Request Seller Responses – Request Seller Responses process obtains information, quotations, bids, offers, or proposals from sellers as appropriate. This is a part of the executing process group


• Select Sellers – The Select Sellers process is where the offers are reviewed, and a chosen vendor rises to the top of the Analytical Hierarchy Process. Commonly negotiations are started in written form. This is commonly a part of the executing process group.


• Contract Administration - The Contract Administration Process manages all aspects of the contract and the relationship between the buyer and the seller including managing seller performance and changes, providing a basis for future work, and managing the relationship with the project’s buyer. This is a part of the monitoring and controlling process grouping.


• Contract Closure - The Contract Closure Process assures completion and settling terms of any contracts including resolving any open items and closing each contract.

Each Procurement Management process results in a specific deliverable which is used as the foundations for the subsequent process. Combined the procurement management processes provide a best practice pattern for managing contracts and vendor relationships on a project.

Risk monitoring and control is the process of identifying, analyzing, and planning for newly discovered risks and managing identified risks. Throughout the process, the risk owners track identified risks, reveal new risks, implement risk response plans, and gage the risk response plans effectiveness. The key point is throughout this phase constant monitoring and due diligence is key to the success.
The inputs to Risk Monitoring and Control are:

• Risk Management Plan - The Risk Management Plan is details how to approach and manage project risk. The plan describes the how and when for monitoring risks. Additionally the Risk Management Plan provides guidance around budgeting and timing for risk-related activities, thresholds, reporting formats, and tracking.


• Risk Register – The Risk Register contains the comprehensive risk listing for the project. Within this listing the key inputs into risk monitoring and control are the bought into, agreed to, realistic, and formal risk responses, the symptoms and warning signs of risk, residual and secondary risks, time and cost contingency reserves, and a watchlist of low-priority risks.


• Approved Change Requests – Approved change requests are the necessary adjustments to work methods, contracts, project scope, and project schedule. Changes can impact existing risk and give rise to new risk. Approved change requests are need to be reviews from the perspective of whether they will affect risk ratings and responses of existing risks, and or if a new risks is a result.


• Work Performance Information – Work performance information is the status of the scheduled activities being performed to accomplish the project work. When comparing the scheduled activities to the baseline, it is easy to determine whether contingency plans need to be put into place to bring the project back in line with the baseline budget and schedule. By reviewing work performance information, one can identify if trigger events have occurred, if new risk are appearing on the radar, or if identified risks are dropping from the radar.


• Performance Reports - Performance reports paint a picture of the project's performance with respect to cost, scope, schedule, resources, quality, and risk. Comparing actual performance against baseline plans may unveil risks which may cause problems in the future. Performance reports use bar charts, S-curves, tables, and histograms, to organize and summarize information such as earned value analysis and project work progress.

All of these inputs help the project manager to monitoring risks and assure a successful project.
Once the risk owner has gathered together all of the inputs, it is time to engage in risk monitoring and controlling. The best practices provided by PMI are:

• Risk Reassessment - Risk reassessment is normally addressed at the status meetings. Throughout the project, the risk picture fluctuates: New risks arise, identified risks change, and some risks may simply disappear. To assure team members remain aware of changes in the risk picture, risks are reassessed on a regularly scheduled basis. Reassessing risks enables risk owners and the project manager to evaluate whether risk probability, impact, or urgency ratings are changing; new risks are coming into play; old risks have disappeared; and if risk responses remain adequate. If a risk's probability, impact, or urgency ratings change, or if new risks are identified, the project manager may initiate iterations of risk identification or analysis to determine the risk's effects on the project plans.


• Status Meetings –Status meetings provide a forum for team members to share their experiences and inform other team members of their progress and plans. A discussion of risk should be an agenda item at every status meeting. Open collaborative discussions allows risk owners to bring to light risks which are triggering events, whether and how well the planned responses are working, and where help might be needed. Most people find it difficult to talk about risk. However, communication will become easier with practice. To assure this is the case, the project manager must encourage open discussion with no room for negative repercussions for discussing negative events.


• Risk Audits - Risk audits examine and document the effectiveness of planned risk responses and their impacts on the schedule and budget. Risk audits may be scheduled activities, documented in the Project Management Plan, or they can be triggered when thresholds are exceeded. Risk audits are often performed by risk auditors, who have specialized expertise in risk assessment and auditing techniques. To ensure objectivity, risk auditors are usually not members of the project team. Some companies even bring in outside firms to perform audits.


• Variance and Trend Analysis - Variance analysis examines the difference between the planned and the actual budget or schedule in order to identify unacceptable risks to the schedule, budget, quality, or scope of the project. Earned value analysis is a type of variance analysis. Trend analysis involves observing project performance over time to determine if performance is getting better or worse using a mathematical model to forecast future performance based on past results.


• Technical Performance Measurement - Technical performance measurement (TPM) identifies deficiencies in meeting system requirements, provide early warning of technical problems, and monitor technical risks. The success of TPM depends upon identifying the correct key performance parameters (KPPs) at the outset of the project. KPPs are factors that measure something of importance to the project and are time/cost critical. Each KPP is linked to the work breakdown structure (WBS), and a time/cost baseline may be established for it. The project manager monitors the performance of KPPs over time and identifies variances from the plan. Variances point to risks in the project's schedule, budget, or scope.


• Reserve Analysis - Reserve analysis makes a comparison of the contingency reserves to the remaining amount of risk to ascertain if there is enough reserve in the pool. Contingency reserves are buffers of time, funds, or resources set aside to handle risks that arise as a project moves forward. These risks can be anticipated, such as the risks on the Risk Register. They can be unanticipated, such as events that "come out of left field." Contingency reserves are depleted over time, as risks trigger and reserves are spent to handle them. With constraints as above monitoring the level of reserves to assure the level remains adequate to cover remaining project risk, is a necessary task.

Outputs of the Risk Monitoring and Control process are produced continually, fed into a variety of other processes. In addition, outputs of the process are used to update project and organizational documents for the benefit of future project managers. The outputs of Risk Monitoring and Control are:

• Updates to the Risk Register – An updated Risk Register has the outcomes from risk assessments, audits, and risk reviews. In addition it is updated with the resulting outcome of the project risk and risk response. Was it a good response, did the response have the desired affect? The updated Risk Register is a key part of the historical record of risk management for the project and will be added to the historical archives.


• Updates to Organizational Process Assets - Organizational process assets should be documented in ligh of the risk management processes to be used in future projects. Documents as the probability and impact matrix, risk databases, and lessons-learned information, as well as all of the project files are archived for the benefit of future project managers.


• Updates to the Project Management Plan - Updates to the Project Management Plan occur if any approved changes have an impact on the risk management process. In addition, these authorized changes incur risks which are documented in the Risk Register.


• Recommend Corrective Actions - Recommended corrective actions consist of two types: contingency plans and workaround plans. A contingency plan is a provision in the Project Management Plan that specifies how a risk will be handled if that risk occurs. The plan may be linked with money or time reserves that can be used to implement the plan. A workaround plan is a response to a negative risk that was passively accepted or not previously identified.


• Recommend Preventative Actions – Recommended preventative actions assure the project follows the guidelines of the project management plan.


• Requested Changes – Requested Changes are any identified changes to the project management plan. Change requests are completed and submitted to the Integrated Change Control process. All requested changes must are documented, and that approvals at the right management levels are sought and obtained.

Risk response planning is the process of developing options to minimize threats and maximize opportunities. The risk response should be inline with the significance of the risk, cost-effective, and realistic. Normally a collaborative discussion needs to occur to assure the best option is the response. In order to begin risk response planning, you need the following inputs to the process:

• Risk Management Plan – The risk management plan contains key components which will help to yield response options. Roles and Responsibilities from the Risk Management Plan define who as the authority to act and who can be an owner of a risk. Risk Analysis Definitions clearly relate the definition of risk ratings for probability, impact, and urgency. Risk Thresholds relate the stakeholders’ tolerance of high, moderate, and low risks. Normally clearly defined thresholds specific to time, cost, and resource amounts are given. Timing and schedules which detail the frequency and activities are also related as a part of the risk management plan.


• Risk Register – The risk register contains the resulting risks from the identification, qualitative analysis, and quantitative analysis. The components used are the priority list of Project Risks, list of near and long-term risks, trends in qualitative risk analysis, categorized risks, and a watch list of low priority risks.

The strategies for handling risk comprise of two main types: negative risks, and positive risks. The goal of the plan is to minimize threats and maximize opportunities.

• Response Strategies for Threats (Negative Risks) – When dealing with threats, there are three main response strategies – Avoid, Transfer, Mitigate (ATM)
  
  
  • Avoid – Risk avoidance involves changing the project plan to remove the threat to the project plan. This can be done by changing or reducing the scope of the project.
  
  
  • Transfer – Risk transference involves shifting the impact of a risk event and the ownership of the risk response to a third party. This strategy is common with a financial risk exposure and involves payment of a risk premium to the party assuming the risk.
  
  
  • Mitigate – Risk Mitigation reduces the probability or impact of a potential risk even to a more acceptable level. This included reducing the consequences of the risk. Mitigation could involve adopting a less complicated process, conducting additional test on the product, designing redundancy into a system, and designing a quality control or reconciliation.


• Response Strategies for Opportunities (Positive Risks) – When dealing with opportunities, there are three main response strategies – Share, Enhance, Exploit (SEE)
  
  
  • Share – Risk sharing involves sharing responsibility and accountability with another to enable the team the best chance of seizing the opportunity.
  
  
  • Enhance – Risk enhancement increases the probability an opportunity will occur by focusing on the trigger conditions of the opportunity and optimizing the chances.
  
  
  • Exploit – Risk exploitation is used on opportunities when the organization wishes to assure the opportunity is realized. Commonly used by hiring the best experts or assuring the most technologically advanced resources are available to the project team.


• Response Strategies for Both Threats and Opportunities – Risk acceptance is any decision not to change to deal with a risk. Risk acceptance is either passively accepted by doing nothing or actively by establishing a contingency reserve.


• Contingent Response Strategy – A risk contingency is used only when a risk is realized or impacting. A response plan is commonly executed when a condition or trigger event occurs. For example missing an intermediate milestone.

Risk Response Planning is the most important risk management process. It places a plan in play of how to deal with risk. The outputs of Risk Response Planning are:

• Risk Register (updates) – Risk Register updates of the appropriate risk response.


• Project Management Plan (updates) – Project Management Plan updates occur as response actions are added after being processed though integrated change control.


• Risk-Related Contractual Agreements – Risk related contractual agreements for insurance, partnerships and services will generate language specifying each party’s responsibilities.

Quantitative Risk Analysis is completed on the prioritized risks from Qualitative Analysis studying the affect of risk event deriving a numerical value. Quantitative Risk Analysis is performed to access the probability of achieving specific project objectives, to quantify the affect of the risk on the overall project objective, and to prioritize the risk based on significance to overall project risk.
The inputs for Quantitative Risk Analysis are:

• Organizational process assets - Organizational process assets uitilized are any information from the project archives on project of a similar nature, any study by risk specialist on a similar project, and any available proprietary risk database.
• Project Scope Statement - The Project Scope Statement provides information on whether the project is a new and exciting endeavor with a significant change in process. These types of project have high levels of risk.
• Risk Management Plan - The Risk Management Plan contains the budget, the definitions of probability and impact, the probability and impact matrix, risk categories, and risk timing and schedule. All of these components are needed to perform Quantitative risk analysis.
• Risk Register - The Risk Register lists the threats and opportunities the project team has identified and has the categories and priority from qualitative risk analysis.
• Project Management Plan – The project management plan has the schedule management plan and cost management plan. The schedule management plan details how to control the project schedule and the cost management plan describes how to budget and control project costs.

In order to accurately perform Quanitiative Risk Analysis, one needs to keep in mind the purpose or outcome is to have a well thought through and realistic number is the probabilistic analysis. The first methodology is to endeavor on a data gathering mission, gathering SMART data, validating the data, and illustrating in a graphical format. The other methodology is to perform a statistical anlysis on the data. Given the two methodologies, the tools and techniques used to perform Quantitative Risk Analysis are:

• Interviewing – Interviewing is employed to assess the probabilities of achieving specific project objectives based on input from relevant stakeholders and subject matter experts. In the interview it is a good mix to obtain the optimistic, pessimistic, and most likely scenario for a given objective. The end result is to have a bought into, agreed to, realistic and formal gage of probability. There are three methods commonly employed:
  • Direct – Direct interviewing is when a subject matter expert is accountable for providing the optimistic, pessimistic, and most likely values.
  • Diagrammatic – Diagrammatic method utilizes diagrams for subject matter experts to determine subjective possibilities.
  • Delphi – The Delphi technique lets a group of experts anonymously contribute their assessment.
• Probability Distribution – A probability distributions describes how probabilities are distributed upon events. It is used to graphically illustrate risk probability representing the probability density function. The vertical axis indicates the probability of the risk even, and the horizontal axis depicts the impact of the risk event.
• Sensitivity Analysis – Sensitivity analysis measures the impact of one risk with all other variables at a level plane. The risk currently being analyzed is given variable values based upon the possible outcomes. This is a great method to ascertain the impact of a single risk, however the method does not yield a combine effect for risk analysis.
• Expected Monetary Value – Expected monetary value analysis calculates the average outcome when the future is not set in stone. In order to calculate EMV multiply the monetary value of a possible outcome by the probability it will occur. EMV analysis is commonly used in conjunction with decision tree analysis.
• Decision Tree Analysis – Decision tree analysis is a detailed review of the information available to evaluate different outcomes. Decision trees enable the considertionof probability and impact for every branch of the decision under analysis. Solutions are based on alternatives which provide the greatest expected value when every implication, costs, rewards, and subsequent decisions are considered.
  Download Sample file
• Modeling and Simulation – A model is mock-uup of a system or problem. A simulation imitates functionality. A common model and simulation is the Monte Carlo Analysis. It illustrates how processes can occur under different conditions, without risk to the production systems and data. The steps to perform a Monte Carlo Analysis are:
  1. Establish a Range of Values for Each Task
  2. Determine the Probability Distribution for Each Task
  3. Choose Random Values for the Simulation
  4. Perform the Simulation
  5. Analyze the Data

The sole output of the Quantitative Risk Analysis process is an updated Risk Register. Components of the output of Quantitative Risk Analysis (updates to the Risk Register) are:

• Probabilistic analysis of the project - The probabilistic analysis of the project is comprised of possible schedule and cost outcomes including estimated completion dates and costs, along with associated confidence levels. This information provides a foundation for prioritizing risks and managing trends in risks and risk results.
• Probability of achieving cost and time objectives - The probability of achieving the cost and time project objectives is pretty self explanatory. Mainly this is a way to quantify the contingency reserves to an acceptable level for the organization. Contingency reserves are the funds, budget, or time needed above the estimate to reduce the risk of overruns of project objectives to a level acceptable to the organization. A probabilistic analysis of your project can be used to calculate and set aside sufficient contingency reserves to cover potential shortfalls.
• Prioritized list of quantified risks – The prioritized list of quantified risks clearly identifies which risks pose the greatest threat or opportunity to the project by requiring a large risk contingency or by influencing the critical path.
• Trends in quantitative risk analysis - When project managers examine quantitative analysis results over time, they often spot trends. Observing and responding to trends can help you identify and eliminate root causes of risk, reduce risk probability, or control risk impact. Managing trends contributes to making you a successful risk manager.

The output of Quantitative Risk Management provides information for handling a project's most threatening risks and promising opportunities. A probabilistic analysis assists you with estimating contingency reserves to ensure stakeholder comfort.

Quantitative Risk Management helps to assess the probability of meeting time and cost objectives. Prioritizing high-threat risks allows one to respond proactively before the iceberg has hit. Monitoring trends enables you to adjust risk management activities over time. Taken together, all of these outputs help you to be a successful risk manager.

Qualitative Risk Analysis assesses the impact and likelihood of the identified risks in a rapid and cost-effective manner. By evaluating the priority of risks with consideration to impact on the project's cost, schedule, scope and quality objectives, Qualitative Risk Analysis provides a foundation for a focused quantitative analysis or Risk Response Plan.
The inputs to the Qualitative Risk Analysis process are:

• Organizational process assets - Organizational process assets are any of your company's policies or procedures which assist in understanding the current project's risks. Another component of organizational process assets is information regarding risks from previous projects. This information yields understanding of how a risk was either successfully or unsuccessfully managed in the past, provides insights into the departments or organization's risk tolerance, and may provide a standard operating policy of how risks are to be managed.


• Project Scope Statement - The Project Scope Statement details the project objectives, deliverables, assumptions, constraints, schedule, budget, and configuration management requirements. Typically a component of the project scope statement is whether the technology or process is a new endeavor for your organization. As we all know the bleeding razor edge is wrought with high levels of risk.


• Risk Management Plan - The Risk Management Plan details the roles and responsibilities, risk management budgets, risk management scheduled activities, risk categories, probability and impact definitions, probability and impact matrix, and stockholder's risk tolerances. These components are useful in risk analysis.


• Risk Register - The Risk Register is a listing of the risk the project team identified.

Once you have garnered all of the inputs it is time to perform qualitative risk analysis. Thankfully there are best practices which are usefully to rate and prioritize the project risks in a rapid and cost-effective manner. These tools and techniques are:

• Risk probability and impact assessment - Risk probability and impact is the team rating of the project's risks and opportunities. It is best to use a team of project members, subject matter experts, individuals listed on the roles and responsibilities section of the risk management plan, and any other usefule knowledgeable participants. There are to tactical methods for deriving a risk rating. First have a meeting with the team. Secondly conduct risk interviews. Generally, the first approach is to tackle the probability question of all identified risks, then review and determine the impact of all identified risks. Finally the risk score is calculated by multiplying probability by impact. The successful outcome of a risk probability and impact assessment is a Risk Register that has been updated with risk ratings for probability, impact, and score.


• Probability and impact matrix - The probability and impact matrix illustrates a risk rating assignment for identified risks. Each risk is rated on its probability of occurrence and impact upon objective. From a spotlight analysis reds are in the high risk zone, yellows are medium risk, and greens are low rated risks which should just be added to the watch list.

  Probability	Threats					Opportunities
  0.900	0.045	0.090	0.180	0.360	0.720	0.720	0.360	0.180	0.090	0.045
  0.700	0.035	0.070	0.140	0.280	0.560	0.560	0.280	0.140	0.070	0.035
  0.500	0.025	0.050	0.100	0.200	0.400	0.400	0.200	0.100	0.050	0.025
  0.300	0.015	0.030	0.060	0.120	0.240	0.240	0.120	0.060	0.030	0.015
  0.100	0.005	0.010	0.020	0.040	0.080	0.080	0.040	0.020	0.010	0.005
  	0.050	0.100	0.200	0.400	0.800	0.800	0.400	0.200	0.100	0.050

• Risk data quality assessment - A qualitative risk analysis needs to have unbiased and accurate data for credibility. A risk data quality assessment is a means to evaluate the reliability and accuracy of the information from which the risk rating is derived.
  1. Extent to which the risk is understood - How well is the risk grokked? The data should be clear, concise and easily explained. Evaluate your data source? Did the wolf caller just tell you another wolf was after the sheep.
  2. Data availability - Is the data complete? A common whole is to base risk ratings on incomplete data.
  3. Data Quality - Is the data timely and relevant? Honestly evaluating a CPOE install by data that is 20 years old isn't good practice. Most like the information isn't timely and relevant.
  4. Data integrity and reliability - How objective is the data? Qualitative Risk Analysis is imprecise; ratings reflect subjective opinions and judgment. However, with this fact in mind, try to obtain the most accurate and unbiased information you can. For example if in a rampant war of office politics, is it objective what stones one side is throwing at the other?
• Risk urgency assessment - Risk requiring near-term responses are have a higher level of urgency than risk way off in the future land.
• Risk categorization - Risks can be grouped in different ways for example they can be categorized by source, area impacted, or project phase.

The output of the Qualitative Risk Analysis process is an updated Risk Register. The risk register updates include:

1. Relative ranking or priority of project risks - The overall risk ranking is determined by summing the individual risk scores and then dividing by the number of risks.
2. Risks grouped by categories - Placing risks in categories reveal areas of risk concentration and highlights common causes of risk. For example, if every risk is surrounding a lack of project resources, then maybe actually planning the project work to the resources available is necessary.
3. Lists of risks requiring response in the near term - The most urgent risks commonly need responses in the short term. By sorting according to urgency, it is easy to identify the most severe risk event which need almost immediate action.
4. List of risks for additional analysis and response - Risks which need additional analysis and management are classified as high sometimes even moderate.
5. Watchlist of low priority risks - Risks which are not urgent and require action in the distant future are commonly detailed on a watchlist for monitoring.
6. Trends in qualitative risk analysis results - With each iteration of Qualitative Risk Analysis, a trend may result which necessitates a response or further analysis.

Further Reading:

• Project Risk Management


• Risk Identification


• Qualitative Risk Analysis


• Quantitative Risk Management


• Risk Response Planning


• Risk Monitoring and Control

Risk Identification ascertains which risks have the potential of affecting the project and documenting the risks' characteristics. Risk Identification begins after the Risk Management Plan is constructed and continues iteratively throughout the project execution. The Risk Identification process naturally progresses into the Qualitative Risk Analysis or the Quantitative Risk Analysis Process. Sometimes it is wise to include the identification of a risk and its response in order for it to be included in Risk Response Planning. At the beginning of the Risk Identification process it is a good idea to have gathered all of the inputs you and your team will need. The inputs to the Risk Identification Process are:

• The Project Management Plan - The Project Management Plan is used in gain an understanding of the project's mission, scope, schedule, cost, Work Breakdown Structure (WBS), quality criteria, and other elements.
• Risk Management Plan - The Risk Management Plan provides the blueprint of overseeing risk management throughout the project describing who, what, when, where, why, and how. The Risk Management Plan provides the following four critical inputs to Risk Identification:
  • Assignment of roles and responsibilities - identifing the who of risk management by assigning the handling of specific tasks and roles to specific individuals.
  • Budget provisions for risk-management activities - The approved funds available for risk-management activities. You will need to track your actual costs against these approved budget numbers.
  • Schedule for risk management - The revised schedule including the time needed for risk-management activities over the duration of the project's life cycle.
  • Categories of risk - The risk categories are used during Risk Identification to organize and prioritize risks as they are identified. Alternatively, the Risk Breakdown Structure (RBS) may be the source of risk categories.
• Project Scope Statement - The project scope statement defines the project boundaries and assumptions. During Risk Identification, risks to boundaries must be identified in order to mitigate scope creep, and assumptions must be reassessed to identify risks associated with them.
• Organizational process assets - Organizational process assets provide information from prior projects including historical information and lessons learned.
• Enterprise environmental factors - These factors include any and all external environmental factors and internal organizational environmental factors that surround or influence the project's success, such as organizational culture and structure, infrastructure, existing resources, commercial databases, market conditions, and project management software.

After gathering all necessary inputs, it is tie to employ the recommended tools and techniques of risk identification. The tools and techniques are:

• Documentation reviews - Documentation reviews involve comprehensively reviewing the project documents and assumptions from the project overview and detailed scope perspective in order to identify areas of inconsistency or lack of clarity. Missing information and inconsistencies are indicators of a hidden risk.
• Information gathering techniques - Information gathering techniques are used to develop lists of risks and risk characteristics. Each technique is helpful for collecting a particular kind of information. The five techniques are:
  • Brainstorming - Brainstorm is employed as a general data-gathering and creativity technique which identifies risks, ideas, or solutions to issues. Brainstorming uses a group of team members or subject-matter experts spring boarding off each others' ideas, to generate new ideas.
  • Delphi technique - The Delphi technique gains information from experts, anonymously, about the likelihood of future events (risks) occurring. The technique eliminates bias and prevents any one expert from having undue influence on the others.
  • Interviewing - Interviewing in a face-to-face meeting comprised of project participants, stakeholders, subject-matter experts, and individuals who may have participated in similar, past projects is a technique for gaining first-hand information about and benefit of others' experience and knowledge.
  • Root cause identification - Root cause identification is a technique for identifying essential causes of risk. Using data from an actual risk event, the technique enables you to find out what happened and how it happened, and understand why it happened, so that you can devise responses to prevent recurrences.
  • Strengths, weaknesses, opportunities, and threats (SWOT) analysis - A SWOT analysis examines the project from the perspective of each project's strengths, weaknesses, opportunities, and threats to increase the breadth of the risks considered by risk management.
• Checklist analysis - Checklists list all identified or potential risks in one place. Checklists are commonly developed from historical information or lessons learned. The Risk Breakdown Structure (RBS) can also be used as a checklist. Just keep in mind that checklists are never comprehensive, so using another technique is still necessary.
• Assumptions analysis - All projects are initially planned on a set of assumptions and what if scenarios. These assumptions are documented in the Project Scope Document. During Risk Identification, assumptions are analyzed to determine the amount of inaccuracy, inconsistency, or incompleteness associated with them.
• Diagramming techniques - Diagramming techniques, such as system flow charts, cause-and-effect diagrams, and influence diagrams are used to uncover risks that aren't readily apparent in verbal descriptions.
  • Cause and effect diagrams - Cause and effect diagrams or fishbone diagrams are used for identifying causes of risk
  • System or process flow charts - Flow charts illustrate how elements and processes interrelate.
  • Influence diagrams - Influence diagrams depict causal influences, time ordering of events and other relationships between input variables and output variables.

The tools and techniques used for the Risk Identification process are designed to help the project manager gather information, analyze it, and identify risks to and opportunities for the project's objectives, scope, cost, and budget. The information gathered is entered on the Risk Register, which is the primary output of Risk Identification.

• Risk Register - The Risk Register containing the results of the Qualitative Risk Analysis, Quantitative Risk Analysis, and Risk Response Planning. The Risk Register illustrates all identified risks, including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status. While the risk register will become the comprehensive output, Risk Identification process results in four entries in the Risk Register:
  1. Lists of identified risks - Identified Risks with their root causes and risk assumptions are listed.
  2. List of potential responses - Potential responses identified here will serve as inputs to the Risk Response Planning process.
  3. Root causes of risk - Root causes of risk are fundamental conditions which cause the identified risk.
  4. Updated risk categories - The process of identifying risks can lead to new risk categories being added.

Further Reading:

• Project Risk Management
• Qualitative Risk Analysis
• Quantitative Risk Management
• Risk Response Planning
• Risk Monitoring and Control

Within Risk Management Planning, it is essential to define risk probability and impact. Commonly an impact scale is developed which reflects the impact of negative impacts of threats or the positive aspects of opportunities. Below is an example which reflects the realive and numeric methods.

Defined Conditions for Impact Scales of a Risk on Major Project Objectives (Examples are shown for negative impacts only)
Project Objective	Very low / 0.05	Low / 0.10	Moderate / 0.25	High / 0.40	Very High / 0.80
Cost	Insignificant cost increase	< 10% Cost Increase	10 - 25% cost increase	25 - 40% Cost Increase	>40% Cost Increase
Time	Insignificant time increase	< 5% Time Increase	5 - 10% Time Increase	10 - 20% Time Increase	> 20% Time Increase
Scope	Scope decrease barely noticeable	Minor Areas of scope affected	Major areas of scope affected	Scope reduction unacceptable to sponsor	Project end item is effectively useless
Quality	Quality degradation barely noticeable	Only very demanding applications are affected	Quality reduction requires sponsor approval	Quality reduction unacceptable to sponsor	Project end item is effectively useless
This table presents examples of risk impact definitions for four different project objectives

Risk Categories are a common listing of sources of risk. Depending on the size of the project, one might employ a Risk Breakdown Structure (RBS).

Download file

The Risk Breakdown Structure is a hierarchical structure which decomposes identified risk categories into sub-categories. Risk categorization helps to identify potential risks for a project.

Risk Management Planning is about defining the process of how to engage and oversee risk management activities for a project. Risk Management planning is an important part of project management. Having a plan on how to manage risk, allows one to task to plan versus innovating and deciding after the fact and in the midst how to handle a risk. The earlier Risk Management planning is engaged within increases the possibility of success of all risk management activities and processes especially if the process definition was created with input and buy-in from the project manager and key project stakeholders.

The inputs for Risk Management Planning are:

• Project Scope Statement – The Project Scope Statement documents the project scope including a description, major deliverables, project objectives, project assumptions, project constraints, and a statement of work. In Risk Management Planning, the project scope statement is commonly used for identifying project boundaries and assumptions.


• Project Management Plan – The Project Management plan contains the WBS which is used in Risk Management Planning to determine possible areas where risks can occur. For example, if the WBS has usability testing being the last item completed after integrated testing. This is a risk. The usability of the application may have affect on how the information is passed into and out of the application. This could be considered a Project Management Planning Risk.


• Organizational process assets – The organizations’ process assets may contain defined standards and policies pertaining to risk management. Process assets included are risk categories, roles and responsibilities, and processes of how to have a decision made.


• Enterprise environmental factors – Enterprise environmental factors reveal the risk tolerance of the organization and the individuals involved in the project. For example, patient billing departments or leaders commonly have absolutely no risk tolerance for any impact to cash flow. This is especially true in non-for-profit organizations like hospitals. However educators and researchers have a high level or risk tolerance. Therefore in an academic medical center, one could have two ranges of risk tolerance. Understanding how much risk your stakeholders and organization are comfortable with help with decisions regarding the type, level, and amount of risk management to apply in the project.

Once the inputs have been obtained the only tool and technique used to engage in risk management planning is the planning meetings and analysis.

• Planning Meetings and Analysis – The planning meetings are used to construct the risk management plan. Commonly attendees are the stakeholders, team members, and the project manager. The Risk costs and action plans are developed with assignments and risk responsibilities. When facilitating planning meetings a couple of tips are:
  • Ensure people can access the inputs to the planning process beforehand – Have a project collaborative a web site and store core project documents including the Project Scope Statement, Project Management Plan, your organization's policies on risk management, and any environmental factors that may affect your project.
  
  
  • Assure the object is to discuss and make decisions about the risk plan – During the Risk Management Planning meetings it is good to cover the five major elements of risk management. These are:
    
    
    1. Methodology — Define how risks will be identified, how risk analysis (qualitative and quantitative) will be done, how risk response planning will happen, how risks will be monitored, and how ongoing risk-monitoring activities will occur.
    
    
    2. Roles and Responsibilities — Determine who will have responsibility for resolving which risks. Create a matrix, list, or table and assign names. Your organization may already have pre-assigned roles and responsibilities.
    
    
    3. Budget — Determine an order-of-magnitude estimate for how much risk-management activities will cost for the project, based on time estimates and personnel costs, and the size, impact, and importance of your project.
    
    
    4. Schedule — Define when risk-management activities should be done, and schedule them. High-visibility, important projects will require more frequent risk identification and response than low-visibility or routine projects.
    
    
    5. Templates and definitions of terms — Obtain copies of your organization's templates and any pre-existing risk categories and definitions. You and your team will need to discuss and agree on what these terms mean.
  
  Risk Management Planning meetings are all about planning for subsequent risk identification and analysis. It's important not to get involved in actually identifying risks during these meetings.

The output of the Risk Management Planning process is the Risk Management Plan. The Risk Management Plan documents Project Risk Management will be structured and performed on the project.

The components of the Risk Management Plan are as follows:

1. Methodology – Methodology describes how the Risk Management processes will be performed, the tools which will be utilized, and the data source for handling risk.


2. Roles and responsibilities – Roles and responsibilities matrix identifies the lead, support, and risk management team for each action item in the risk management plan, and assigns people to the roles clarifying their responsibility and accountability.


3. Budgeting – Budgeting assigns resource and estimates costs needed for risk management. Simply state it is just better to be honest and above board, budgeting for risk with a risk contingency.


4. Timing – Timing clarifies the frequency of the risk management process and schedules some risk management activities in the project schedule. Without timely monitoring and response, risks can easily escalate into negative events or become missed opportunities because you failed to exploit them.


5. Risk categories - Risk categories are potential causes of risk included in the Risk Management Plan for use during the Risk Identification and Risk Analysis processes. Risk categories are sometimes shown as a Risk Breakdown Structure (RBS). The RBS is a hierarchically organized depiction of the identified project risks arranged by risk category and subcategory that identifies the various areas and causes of potential risks.


6. Definitions of risk probability and impact - Agreeing on standard definitions helps to ensure that everyone is communicating on the same wavelength. Definitions are included in the Risk Management Plan for later use during Risk Analysis.


7. Probability and impact matrix - The probability and impact matrix assists in determining whether a risk is considered low, moderate, or high by combining the two dimensions of a risk: its probability of occurrence, and its impact on objectives if it occurs.


8. Revised stakeholder tolerances — As discussions become more specific during planning meetings about actual risks and actual costs, schedules, scope, objectives, and quality criteria, you will begin to get a better idea of your stakeholders' tolerance for risk than you had at the start of the process.


9. Reporting formats – Reporting formats depict the content and format of the risk register. The Risk Register is a document on which you will record identified risks and their characteristics.


10. Tracking – Tracking describes how and when risk information will be documented and reviewed for the benefit of current project, future needs, and lessons learned. Tracking also specifies whether risk management processes will be audited.

Project Risk Management involves conducting risk management planning, engaging in risk identification, completing risk analysis, creating a risk response action plan, and monitoring and controlling risk on a project. Project Risk Management is a continuous process to be engaged in through out the entire project. A key point to remember is that risk is not always bad. There are opportunities and there are threats. The opportunities are the good risks. The treats are the bad risks. The purpose of project risk management is to increase the likelihood and impact of positive events and to decrease the probability and impact of negative events. The six risk management processes are:

1. Risk Management Planning - Risk Management Planning is the process where decisions are made on how to approach, plan, and execute risk management activities. This is completed as a part of the planning process group.
2. Risk Identification - Risk Identification determines the risk which can affect the project's objectives, and identifies the characteristics of those risks. Risk Identification is commonly first engaged in the planning process group.
3. Qualitative Risk Analysis - Qualitative Risk Analysis prioritizes risk for future analysis by analyzing the probability of occurrence and impact. Qualitative Risk Analysis is commonly first engaged within the planning process group.
4. Quantitative Risk Analysis - Quantitative Risk Analysis assigns a number to risks as a part of determining the impact on overall project objectives. Quantitative Risk Analysis is commonly engaged within the planning process group.
5. Risk Response Planning - Risk Response Planning ascertains the options and action plans to enhance the opportunities and mitigate the threats. Risk Response planning is normally first started in the Risk Response Planning Group.
6. Risk Monitoring and Control - Risk Monitoring and Controlling is an ongoing process. It involves overseeing the effectiveness of risk responses, monitoring residual risks, identifying and documenting new risks, and assuring that risk management processes are followed. This is done throughout the Monitoring and Controlling Process Group.

Each Risk Management process results in a specific deliverable which is used as the foundations for the subsequent process. Combined the risk management processes provide a best practice pattern for managing risk on a project.

Since communicating is about 90% of a project managers time, there is a reason to improve communications on a project. To overcome communication barriers, project managers must establish clear lines of communication and keep stakeholders constantly informed about the development of the project. The following techniques can help:

• Keep a thorough knowledge of stakeholders' needs - Once people or organizations with a stake in the project are identified, you could invite those stakeholders to meetings or conference calls designed to elicit information regarding their needs. You might ask them about the format that best meets their needs, as well.
• Use stakeholders' preferred method of interaction - It is important to find out from your stakeholders what communication channels they prefer--face-to-face, telephone, online, or hard copy. You can ask them in a meeting, by phone, or in a questionnaire. At the same time, you should gather relevant contact information.
• Keep an open-door policy - To strengthen information sharing, tell stakeholders--via their preferred method of interaction--when you are available and invite their comments and questions. You could suggest the best time or way to reach you, or set aside particular times for them.
• Interpret and clarify policies and procedures - Once you've consulted with stakeholders and developed communications policies and procedures, you must be sure they're understood. You can provide them in writing and then follow up by providing interpretation and clarification in meetings, on the telephone, or by e-mail.
• Motivate staff and foster teamwork - You can motivate stakeholders to interact with one another by reminding them that they require each other's contributions in order to succeed. You should convey this general message formally and informally, and reiterate it in particular situations where it applies.

Frankly, miscommunication can quickly derail a project. Miscommunication commonly takes place when people issues are mishandled. Stakeholder management illustrates how to manage communications with stakeholders focusing on the needs of the stakeholders and the issues that arise from the stakeholders. The project manager is normally responsible for stakeholder management.

The inputs for managing stakeholders are:

• Communications Management Plan - The Communications Management Plan outlines how project communications will be addressed. It describes the frequency and medium for communications, and identifies those responsible for communicating with stakeholders. It specifies stakeholders' requirements and expectations. This plan should contain the best methods for communication with the stakeholders that have been bought into, agreed, are realistic, and formal.
• Organizational process assets - Organizational process assets are any or all process-related assets which can influence the project's success. Team members need to know the company's processes and procedures in order to understand how these assets will influence and affect the project. Organizational process assets commonly include: documented lessons learned, policies and procedures, guidelines, and best practices.

The inputs to the Manage Stakeholders process provide critical information about what processes to follow when communicating with stakeholders.

There are two tools and techniques used in managing stakeholders. These tools and techniques are:

1. Communication methods - Communication methods are listed in the communication management plan. Commonly face to face meetings are the most effective way for communications after all body language is a very telling means of communication. However there are times when face to face meetings are a luxury which can’t be justified. In these situations possible communication methods are: traditional mail, electronic mail, phone calls, an extranet site, ftp site, Internet meeting, face-to-face meeting, or videoconferencing.
2. Issues log – The issues logs is a document which can be used to facilitate communication. An issues log documents project issues and relays how these issues get resolved. The project manager clarifies each issue, identifies a person accountable for resolving the issue, and sets a target date for resolution of the issue. This is a great reference tool that provides details that normally might get lost with the passing of time. Having an issues log will prove invaluable when communicating with others about their concerns. From a single source of truth perspective, it is best to have only one issues log per project. Having 3 people keep 3 different issues logs is just added unnecessary confusion.

Understanding what communication methods to use and knowing how to monitor and document issues helps project managers effectively manage stakeholders and keep their projects on course. Can you imagine being on a project where everyone communicates every which way with no formal issues system? Shivering yet?

The result of managing stakeholders will be actions, documentation, and updates to existing documents or procedures. The resulting process outputs are:

• Resolved Issues – Resolved issues are the stakeholder requirements which have been identified and resolved.
• Approved Change Requests – Approved change requests are derived from the resolution of stakeholder issues which lead to changes in the project plan and activities. These changes have all gone through the formal integrated change control process.
• Approved Corrective Actions – Approved corrective actions are actions which will brng the project back to task with expectations and objectives detailed in the Project Management Plan.
• Organizational Process Assets – Organizational Process Assets that are updated due to outcomes from stakeholder management. These commonly are lessons learned documentation including the root cause of the issue, the reasoning behind the corrective action chosen, and other types of lessons leaned during stakeholder management.
• Project Management Plan (updates) – Updates to communication management plan are reflected in the Project Management Plan.

The most critical output of the Manage Stakeholders process is that the issues get resolved and that solutions are put into place effectively. Issue resolution means project progression.

Performance reporting is the process of collecting all baseline data and distributing performance information to stakeholders and the project. An aspect of this report is to clarify how resources are being used to obtain the objectives of the project. This should be done in conjunction with providing information on scope, schedule, cost, risk, procurement, and quality. In my experience this is normally a good activity to complete with regular frequency.

The inputs to performance reporting are:

• Work performance information - Work performance information details the work that is being executed, recently completed, and next steps. This information is gathered from the Direct and Manage Project execution process.
• Performance measurements – Performance measurements are the earned value indexes: Cost Variance, Schedule Variance, the Cost Performance Index, Schedule Performance Index, Planned Value, Earned Value, and Actual Cost. Performance measurements assist in reporting unbiased and quantifiable information – an excellent mechanism for accountability.
• Forecasted completion - Forecasted completion is the predictor of potential project roadblocks. Commonly, forecasted completion is expressed through two factors: estimate at completion (EAC) and estimate to complete (ETC). These are useful tools to predict completion and the expense to get to that state.
• Quality control measurements - Quality control measurements result from activities comparing the results to the quality standards and processes. This is the true check to assure a quality product or service has been provided
• Project Management Plan - The Project Management Plan contains the Performance measurement baseline which contains the approved measures for management control.
• Approved change requests - Approved change requests are requested changes that have bee that have been approved and are ready to be implemented. They are used to determine project changes that have been formally approved and must be communicated to stakeholders through integrated change control.
• Deliverables - Deliverables comprise the quantifiable actions, results, products, or capabilities that will be produced in order to complete the project.

The inputs to performance reporting are absolutely necessary to providing an accurate quantifiable performance report. Without this information your report may sound like it was created by Captain Fluff.

Once you have all the inputs to the process, let’s look at some common tools and techniques used with the performance reporting process. The tools and techniques for performance reporting are:

• Information presentation tools - Information presentation tools enable the project team members to present project performance data. Most organizations have software packages which can be used to paint a picture with a graph or a spreadsheet analysis.
• Performance information gathering and compilation - The performance information gathering and compilation technique is the organizing of all pertinent project information.
• Status review meetings - Status review meetings are regularly scheduled meetings to exchange information about a project. Commonly there is a team level status review meeting and then an executive over site review meeting.
• Time reporting systems - Time reporting systems record and provide information about the time spent for activities on a project.
• Cost reporting systems - Cost reporting systems record and provide the costs expended for the project.

Using these tools and techniques help to have an efficient reporting process. Imagine if the only way to obtain time spent on a project was to review every team members time sheet and then sum up the parts. What an archaic way to manage a business! Also this would truly eliminate the efficiency of the project manager.

The Performance Reporting process provides pertinent and verifiable documentation of project performance. The outputs of the Performance Reporting process are:

• Performance reports - Performance reports are presentations and documents that summarize work performance information in the form of bar charts, S-curves, histograms, and tables.
• Forecasts - Forecasts are predictions of what will occur based on the project performance to date. Forecasts are updated and reissued as new work performance information is available during project execution. A project manager might want to conduct a trend analysis of cost and schedule variance to see how on budget and on time the project is likely to be.
• Requested changes - Requested changes are project changes affecting scope that are submitted to the Integrated Change Control process. These must be reflected in performance reporting to stakeholders.
• Recommended corrective actions - Recommended corrective actions are documented suggestions affecting project execution designed to ensure that expected future project performance will conform to the Project Management Plan. Once a project manager is made aware of a schedule or cost variance, he needs to take action to get the project back in line with original objectives. To do so, recommended corrective actions may be offered.
• Organizational process assets updates - Organizational process assets updates are changes or updates to formal and informal policies, plans, guidelines, organizational best practices, and lessons learned from project experience.

When one begins to contemplate how important communication is to project success, it is also interesting how common barriers to communication become. Communication barriers often present an obstacle to delivering a successful project. Project Managers should be considerate of the frequently occurring barriers in order to assure there are no developing issues.
The most common barriers to good communications are:

• Misunderstanding other stakeholders' information needs - Misunderstanding commonly occurs when the project team doesn't understand the informational needs of other stakeholders. In this situation, information can be distributed inappropriately and inconsistently.
• Using media improperly - The media selected to communicate must be able to be used by all stakeholders and project team members. It does no good to send the Microsoft project version of the work break down structure when the team doesn't understand how to read the project plan.
• Isolating decision makers - The silo-ed decision maker can impede a successful project. Decision makers who isolate themselves or don't respond to requests for information are a common communication barrier.
• Misapplying policies and procedures - Team mates and stakeholders who don't follow the prescribed communication policies and procedures create confusion. These communications are commonly incomplete containing inaccurate information and are directed to the incorrect audience.
• Underestimating the importance of teamwork - Insensitivity to teamwork results in isolationists not distributing the information in a timely accurate way. A key signal that this problem exists is when team members don't participate in team-building activities.

Good communications create constructive attitudes and knowledge and take time to establish.

Further Reading:

• Ways to Improve Communication


• Information Distribution according to PMI

Information Distribution is about assuring the right information is available to the right people at the right time. Information Distribution executes the communication plan and responds to the unexpected requests for information.
The distribution mechanism can affect the information’s usefulness because if it is not timely or comprehended, then it shouldn’t have been communicated.

The only input to information distribution is:

• The Communications Management Plan – The Communications Management plan describes the methods for obtaining and distributing project information. The communication management plan provides:
  1. Stakeholder communication requirements
  2. Information to be communicated, including format, content, and level of detail
  3. Individual accountable for communications
  4. Recipients of the information
  5. Communication Methodology or Technology
  6. Frequency of Communication
  7. Escalation process with associated time frames
  8. Change control process for the communication plan
  9. Dictionary of related jargon

After reviewing the communications management plan, there are certain tools and techniques which can be employed to distribute information. The four tools and techniques are:

1. Communications skills – Communication Skills enable a project manager to take advantage of the dimensions of communication.
2. Information Gathering and Retrieval Systems – Information Gathering and Retrieval systems are all of the various ways to collect and share project documentation. Possible mechanisms are a manual filing system, electronic databases, collaboration software, and a project management information system.
3. Information Distribution Methods – Information distribution is the timely collection, sharing and distribution of information to the project team. Methods can be portals, collaborative work management tools, web conferencing, web publishing, and when all technology is not available, manual filing systems and hard copy distribution.
4. Lessons Learned Process – Lessons learned identify project success and failures from which knowledge can be gathered to make recommendations to improve future performance on projects. Some specific results from lessons learned include:
   • Update of the lessons learned knowledge base
   • Input to knowledge management systems
   • Updated corporate policies, procedures, and processes
   • Improved business skills
   • Overall product and service improvements
   • Updates to the risk management plan

The purpose of communicating is to exchange information it is best to assure all intended receivers can use the distribution methodology. The outputs from Information Distribution are:

1. Updates to the organizational process assets - Organizational process assets (updates) are used to update the project knowledge base. Updates to the organizational process assets include the following:
   • Lessons learned – Documentation includes the root cause of issues, strategies for preventing this from ever occurring again. Project management processes that can be improved, as well as recommendations on any enhancements or modifications.
   • Project Records – Project records include all correspondence and documents describing the project. This would be also in the form of a project notebook.
   • Project Reports – Formal and information project reports catch the project status, issues, and progress reports.
   • Project presentations – Project presentations are the information presented to the project stakeholders. This information is the foundation of the stakeholders view of the project.
   • Feedback from stakeholders – Feedback received from stakeholders should be used to modify or improve future project performance
   • Stakeholder Notifications – Information provided to stakeholders about resolved issues, approved changes, and general project status
2. Requested changes – Requested changes to the project management plan should be handled through the integrated change control process.

As a part of communicating, the sender is accountable for assuring the information is clear, complete, and comprehendible to the intended recipient. The recipient is responsible for understanding the information and making sure it was received in its entirety. Due to this structure, communication has many dimensions.

• Written and oral, which includes listening and speaking - Written communications include such activities as writing reports and executive summaries, and writing e-mails. Oral communications include giving oral presentations, communicating within a group context, and communicating one-to-one. Listening and speaking skills also are important in ensuring that project information has been distributed properly.
• Internal and external - Internal communications are information exchanges that take place within the organization itself. External communications involve stakeholders and customers who are not officers or employees of the organization – vendors, customers and the media are a typical example.
• Formal and informal - Formal communication involves formal deliverables, such as briefings and status reports describing any key accomplishments and concerns. Informal communications may include phone conversations, e-mail, and adhoc conversations.
• Vertical and horizontal - Vertical communications are directed at persons who are at different levels within the corporate hierarchy. Horizontal communications take place with persons who have similar levels of responsibility and authority your peers.

Project Managers are always involved in communications, and a key to success is understanding the various ways to interact with peers, team mates, stakeholders, and others within and outside of an organization.

Communications Planning determines which stakeholders need what information, when they will need it, how the information will be communicated, and who is responsible for communicating the information. One of the key task is to assure a reliable way to meet the informational needs of the stakeholders which is linked to the enterprise environmental factors and organizational influences.

The inputs to communication planning are:

1. Enterprise environmental factors - External and internal environmental factors influence the project's success. Examples: organizational culture and structure, infrastructure, existing resources, and communications technology.
2. Organizational process assets – Organizational process assets represent the knowledge learned and documented from previous organizational endeavors. Some organizational process assets are formal and informal plans, policies, procedures, and guidelines.
3. Project Scope Statement – The project scope statement describes the project scope including major deliverables, scope objectives, scope assumptions, scope constraints, and a statement of work.
4. Project Management Plan – The project management plan is the bought into, agreed to, realistic, and formal document detailing how the project will be executed, monitored and controlled. Assumptions and constraints may affect communications and should be considered.

When you use the proper inputs for Communications Planning, you will feel confident that you have a solid foundation for your Communications Management Plan. As project manager, you will want to use the proper tools and techniques to develop a communications plan from the inputs you have gathered. The two tools and techniques for communications planning are:

1. Communications requirements analysis – Communications requirements analysis determines the information needs of the stakeholders. By combining the type and format of information needed considering the information’s value to the audience. The goal is to walk the balance between overwhelming with too much granular information to too little high level reviews.
   In order to ascertain the project communications requirements, the project manager reviews:
   • Organization Charts
   • Project organization and stakeholder responsibility relationships
   • Disciplines, departments, and specialties engaged in the project.
   • Logistics of how many individuals are involved with the project at which locations.
   • Internal information needs
   • External information needs
   • Stakeholder information
2. Communications technology – The communication technology describes the methodology utilized to communicate with the stakeholders. This can include sharepoint, video cam meeting or minutes.
   When considering which communications technology to use, please consider the following:
   • The urgency of the information
   • The availability of the technology
   • The expected project staffing
   • The length of the project
   • The project environment

When determining which communication tool and technique to use, it is a good idea to keep in mind the channels of communication. The total number of communication channels is n(n-1)/2, where n is the number of stakeholders. The number of potential communication channels is an indicator of project’s communications complexity.

The output of communications planning is the Communications Management Plan. The communication management plan is comprised of the following information:

• Stakeholder communication requirements
• The format utilized
• The individual responsible for assuring communications
• The information recipients
• The form of communication (email, conference calls)
• The frequency of the communications
• Escalation time frames and management change for escalation
• The change control process for updating the communications plan
• A glossary of terminology and jargon

A Communications Plan clarifies the project's communications requirements and establishes communication strategies.

Project Communications Management Knowledge area provides a critical link between people, ideas, and information at all stages in the project life cycle. Project Managers should be spending about 90% of their time communicating. Formal processes aid in decision making and help to achieve a successful project.
The Project Communications Management processes are:

• Communications Planning – Communications planning is the process of ascertaining the information and communication needs of project stakeholder. This process normally occurs as a part of the Planning Process Group.
• Information Distribution – Information Distribution is the process of assuring the project stakeholders have the needed information available in a timely manner. This process occurs throughout the Executing Process Group.
• Performance Reporting – Performance reporting is the process of gathering and distributing project performance information including status reporting, progress measurement, and forecasting. This process occurs within the Monitoring and Controlling Process Group.
• Manage Stakeholders – Managing Stakeholders occurs within the Monitoring and Controlling Process Group. Managing stakeholders is concerned with satisfying the requirement for the project stakeholders and resolving any issues raised by the project stakeholders.

It is a good idea to remember that activities and responsibilities under the above process will depend upon the project on hand. A smaller project obviously will not have the same communication standard as a larger project.

The important point is that all communication should be effective, accurate, and considerate of project requirements.
The project communication processes provide a methodology for successfully implementing your project communications strategy. In addition to assuring stakeholders are informed and involved in the project.

Harold Kerzner identifies five levels for achieving excellence in
project management (PM).

Level 1: Common Language is the basic knowledge of PM and the
terminology used.

Level 2: Common Processes defined and developed are applicable and
repeatable.

Level 3: Singular Methodology is the synergistic effect of combining
all corporate methodologies.

Level 4: Benchmarking process improvement is required to maintain a
competitive advantage.

Level 5: Continuous Improvement evaluates the enhancement to PM from
each improvement.

Which level is your organization currently enjoying? How will your group rise to the next level?

Managing a project team involves tracking individual’s performance, providing feedback, resolving issues, and coordinating changes to enhance overall project performance. In a functional organization it is much like managing a department team with the nuance of enhancing the project’s performance instead of meeting the operational goals of the department.

The inputs to managing a project team yield an overview of project team performance and assignments so the project manager can determine what the next steps are. The inputs are:

• Organizational Process Assets – Organizational process assets are the organization’s policies, procedures, and systems which can be used to reward the team during the course of a project.
• Project Staff Assignments – Project Staff Assignments are the list of project duties for team members. Staff Assignments are often used during the monitoring and controlling process group to evaluate individual team members.
• Roles and Responsibilities – The roles and responsibilities document is used to determine what each team member should be focusing upon and completing.
• Project Organization Charts – Project Charts represent the reporting relationships among the project team.
• Staffing Management Plan – The Staffing Management Plan details when team members are needed and list training plans, certification requirements, and compliance issues.
• Team Performance Assessment - Team Performance Assessments are the documented formal or informal assessment of the project team’s performance. Common indications are staff turnover rates, team dynamics, and skill levels. After analyzing the information, project managers can identify and resolve problems, reduce conflicts, and improve overall team work.
• Work Performance Information – Work Performance information is gathered by observing team members performance while participating in meetings, follow-up on action items, and communicating to others.
• Performance Reports – Performance reports depict project performance information when compared to the project plan. This provides a basis for determining if corrective actions or preventative actions are need to assure a successful project delivery.

Managing a team involves making justifiable decisions about how to address the issues and problems that arise as part of project work. There are some tools and techniques you can use to manage the project team. Those tools and techniques are:

• Observation and Conversation - Observation and conversation involves project managers using indicators such as progress toward project goals, interpersonal relationships, and pride in accomplishments and work of project team members.
• Project Performance Appraisals - Project performance appraisals is a vehicle which enables team members to receive feedback from supervisors. Performance Appraisals can be used them to clarify team member responsibilities and to develop training plans and future goals.
• Conflict Management - Conflict management involves the reduction of destructive disagreements within the project team. The project manager can allow the problem to resolve itself or use informal and formal interventions before the conflict damages the project.
• Issue Log - An issue log is a list of action items and the names of the team members responsible for carrying them out. Issue logs provide project managers with a way to monitor outstanding items.

Often in the course of a project, it is necessary to make changes to the way the project is executed. The outputs of the Managing a Project team process are:

• Requested Changes – Requested Changes are staffing changes either planned or unplanned which can impact the project plan. When staffing changes which have the possibility of disrupting the project plan, the change needs to be processed through integrated change control.
• Recommended Corrective Actions - Recommended corrective actions are to overcoming the addition or removable of a teammate, outsourcing some work, additional training, or actions relating to disciplinary processes.
• Recommended Preventive Actions - Recommended preventive actions are taken to reduce the impact of anticipated problems. Such actions might include cross training a replacement before a team member leaves the project or clarifying roles to ensure that all project tasks are carried out or added personal time in anticipation of extra work which may be needed to meet project deadlines.
• Organizational Process Asset Updates – Organizational process asset updates are either inputs to team members performance appraisals or lessons learned documentation.
• Staffing Management Plan Updates – Staffing Management plan is a subsidiary plan of the project management plan. The staffing management plan is updated to reflect staffing related approved change requests.

Developing a project team improves the overall competencies and collaborations among team mates. This improvement will eventually result in enhanced project performance. The goals of developing a project team is to increase the team’s skill sets and increase trust among teammates.

The inputs to developing a project team are:

• Project Staff Assignments – Project Staff Assignments is a detailed list of the people who are on the team.
• Staffing management Plan – The staffing management plan identifies the way to develop the team, guidelines documenting staff acquisition and release, the timetable, training needs, recognition, compliance, and safety.
• Resource Availability – Resource availability information lists when team members are available to partake in team development activities.

Developing a synergistic project team means knowing who your team members are, helping them build upon their strengths and overcoming their weaknesses while promoting productive working relationships within the team. There are common tools and techniques to develop a project team. They are:

• General Management Skills – The soft skills or interpersonal skills help motivate a team’s performance and collaboration through empathy, influence, communication, creativity, and facilitation.
• Training – Training encompasses improving the skills and knowledge of team members. Possible training methods are classroom training, online learning, on-the-job training, mentoring or coaching
• Team-Building Activities – Team-building activities encourage communication, trust, and collaboration among teammates.
• Ground Rules – Ground rules establish clear expectations regarding acceptable behavior by project team members. The overall teams commitment to ground rules decreases misunderstanding and increases productivity.
• Co-Location – Co-location is the placement of all or most of the active team members in the same physical location to increase team-building opportunities.
• Recognition and Rewards – Recognition and rewards improve project work by achieving recognition and rewarding desired behaviors.
• Establish Empathy – Being empathic is the listening and understanding how the individual team member is feeling. There is a simple process that can be used to establish empathy: encourage openness, restate concerns, reflect, and summarize.

Developing a project team is an ongoing process that needs to be assessed on an ongoing basis. When tools and techniques have been used to develop the project team, the project manager or project management team needs to assess whether the team's effectiveness has improved. The single output from developing a project team is team performance assessment.

• Team Performance Assessment – As the team’s performance improves some indicators to measure the team’s effectiveness are:
  • Improvements in skills which allow an individual to perform assigned activities with increased effectiveness.
  • Improvements in competencies and sentiments which will help the team perform better as a group
  • Reduced staff turnover rate.

Team performance assessment allows project managers to recognize improvements, but it also highlights any difficulties so they can be addressed. If improvements are not noted or problems arise, you may need to revisit some of the tools and techniques you used to develop your project team and start again.

Approach	Description	When to use
Problem - Solving	The problem-solving approach involves supporting the individuals involved in the conflict to help them consider all the options and find the best solution. Sometimes refered to as the Confrontation approach.	This approach should be employed in situations where there is not a clear concise agreed to solution, and there is time to allow the parties to collaborate and innovate. For this approach to work, it is also important that the conflicting parties both bring ideas and creativity to the problem.
Comprise	Comprise involves working out a middle ground that satisfies all parties to some degree. The compromising approach requires each of the conflicting members to accede in order to achieve a resolution.	This approach should be employed in situations when both parties have a valid but different approach to resolve the problem or complete the task hand, or when there is not a best practice to be followed. By assuring everyone's perspective is considered and represented, this approach will allow a win-win situation to occur.
Smoothing	Smoothing de-emphasizes the differences between points of view and focuses on commonalities. The smoothing approach involves minimizing the importance of the problem at the heart of the conflict in an effort to make the conflict seem pointless.	This approach is particularly useful for minor or unimportant issues, or issues that are not critical to project success.
Forcing	The forcing approach requires others to yield to the point of view of one side or another. It is also called the win-lose approach and can increase conflict. The forcing approach involves you, as project manager, using your influence and power within the project team to simply resolve the issue yourself, making a decision about the way to move forward.	This approach should be used when time is a critical factor. It is imperative that the project manager provides the desired resolution to the conflict. This approach doesn't solve the conflict, but it does ensure that things get done.
Withdrawal	Withdrawal involves avoiding or retreating from the conflict or potential conflict and allowing the involved parties to work out the conflict on their own. The withdrawing approach involves giving in to the conflict by simply refusing to acknowledge that there is a problem and declining to discuss it.	Because this approach involves avoiding the problem, it should not be used very often. It can be a temporary solution to deal with heated and emotional conflicts, or it can be used if the issue isn't relevant to the work of the project team.

Acquiring a project team is the process of obtaining the people needed to accomplish the project. Sometimes the project management team has control over the selection process. When selecting teammates, there are several base considerations which need to be evaluated. The inputs to acquiring a project team are:

1. Enterprise Environmental Factors – Teammates are available from internal and external sources. When selecting team members it is important to evaluated:
   • Availability – Who is available and when are they available?
   • Ability – What competencies do people possess?
   • Experience – Have the people done similar or related work? Has the work been of high quality?
   • Interests – Are the individuals interested in working on this project?
   • Costs – How much will each team member be paid? Especially if they are contracted from another organization.
2. Organizational Process Assets – Reviewing the documented policies, procedures, and guidelines governing staff assignments are encompassed in considering the organizational process assets.
3. Roles and Responsibilities – The roles and responsibilities document should be reviewed to ascertain team member’s roles, responsibilities, skills, levels of authority, and competencies.
4. Project Organization Charts – A project organization chart is reviewed to provide an overview of how many individuals are needed for the project.
5. Staffing Management Plan – The Staffing Management Plan, along with the project schedule, should be reviewed to ascertain when team members will be need and to gain understanding of the processed to acquire and release staff.

In order to complete a project, it is helpful to gather the best team available. With the right team, one will have a good foundation to overcome all opportunities presented. The common tools and techniques utilized to help assure the acquisition of a good project team are:

• Pre-assignment – Pre-assignment is commonly done when the project team positions are known in advance. This is commonly when the project is dependent on the expertise of an individual or if staff assignments are defined as a part of the charter.
• Negotiation – Negotiation is used when the pm needs to assure that the project receives competent staff within the required time frame, and that the project team members have the bandwidth to work on their assignments through to completion. Another situation which call for negotiations is when specialized or scare resources are needed to complete the project plan.
• Acquisition – When performing organizations do not have the in-house staff needed to complete the project, the staff acquisitions may be net new resources, consultants, or subcontractors.
• Virtual Teams – Virtual teams are utilized in the following situations:
  1. Teams comprise individuals who are not co-located in the same region
  2. Teams comprise employees who work from home.
  3. Teams consist of individuals from different shifts.
  4. Teams consist of individuals with mobile handicaps
  5. Projects which have no travel budget to co-locate.
  In a virtual team, communications are very important. Also while planning, consider the time added due to increased communications for setting expectations, how to resolve conflicts, and how to include the right individuals in decision making processes.

The results from acquiring the right project team are the same as those desired in any game of strategy. You want to have the right players in the right roles. When you have considered which people you need to complete your project and you have negotiated and secured their services, you have acquired your project team. The outputs resulting from the Acquire Project Team process are:

1. Project Staff Assignments - Project staff assignments illustrate who has been assigned to the project. These assignments should be documented in a team directory, in notifications to team members, in project organization charts, and in schedules.
2. Resource Availability - Resource availability details the time periods when each project team member is or is not available to work on the project.
3. Staffing Management Plan Updates – Changes in the Staffing Management plan may be needed in order to rebase the planned with the real team.

A project manager success starts with creating the best team possible and having the right people in the right roles.

Human Resource Planning defines project roles, responsibilities, and reporting relationships. One key result of Human Resource Planning is the Staffing management plan which depicts how and when team members are added to the team, and how the team members are released from the project, the training needs of the team, and several other key components.

The inputs to Human Resource Planning are:

1. Enterprise Environmental Factors – The Enterprise Environmental Factors that comprise of individuals of an organization interact and relate with one another are an input into Human Resource Planning. Items to considers about enterprise environmental factors involving organizational culture and structure are:
   • Organizational – Which organizations or departments are going to be engaged in the project? Are there existing working arrangements between them? What are the formal and informal relationships between the departments?
   • Technical – What are the areas of expertise needed to successfully complete this project? Do these skills need to be transitioned to the supporting organization?
   • Interpersonal – What types of formal and informal reporting relationships exist among the team members? What are team members current job descriptions? What are their supervisor-subordinate relationships? What levels of trust and respect currently exist?
   • Logistical – Are people in different locations or time zones? What are other type of distances between team members?
   • Political – What are the individual goals and agendas of the stakeholders? Where is the informal power base and how can that influence the project? What informal alliances exist?
   
   In addition to these factors, there are also constraints. Examples of inflexibility in Human Resource Planning are:
   • Organizational Structure – An organization with a weak matrix structure is commonly a constraint.
   • Collective Bargaining Agreements – Contractual agreements with service organizations can require interesting nuances to certain roles and reporting arrangements.
   • Economic Conditions – Hiring freezes, little to no training funds, and a lack of traveling budget can place restrictions of staffing options.
2. Organizational Process Assets - As an organization's project management methods evolve, experience gained from past projects are available as organizational process assets. Templates and checklists reduce the planning time required and the likelihood of overlooking key responsibilities.
3. Project Management Plan - The Project Management Plan contains activity resource requirements and project management activity descriptions which assist in identifying the types and quantities of resources required for each schedule activity in a work package.

With the proper inputs, the results are going to have a good foundation. Project teams use different tools and techniques to guide the Human Resource Planning process. These three tools and techniques are:

• Organization Charts and Position Descriptions - Organization charts and position descriptions are used to communicate and clarify team member roles and responsibilities and to ensure that each work package is assigned. Organization charts can have three formats: Hierarchical-type Organization chart, Matrix-Based Responsibility Chart, and the Text-oriented format.
• Networking – Informal interactions among co-workers in the organization is a constructive way to comprehend the political and interpersonal factors which will affect organizational relations.
• Organizational Theory – Organizational theory portrays how people, teams, and organizational units behave.

The three outputs from Human Resource Planning are found below:

• Roles and Responsibilities - Clarification of roles and responsibilities gives project team members an understanding of their own rles and the roles of others in the project. Clarity is always a key component of project success.
• Project Organization Charts - A project organization chart is a diagram of the reporting relationships of project team members. Project organization charts should be tailored for their audience, they can give a generalize overview or highly granular.
• Staffing Management Plan - The Staffing Management Plan is an important output of the Human Resource Planning process which establishes the timing and methods for meeting project human resource requirements. The components of the staffing management plan are:
  1. Staff Acquisition – Staff Acquisition details how the project will be staffed, where the team will work, and the level of expertise needed with the staff.
  2. Timetable – The timetable illustrates the necessary time frames for project team to be available. One tool commonly used is a resource histogram.
  3. Release Criteria – Release criteria lists the method and timing of releasing team member.
  4. Training Needs – Training needs is a plan on how to train the project resources.
  5. Recognition and rewards – Recognition and rewards are the criteria for rewarding and promoting desired team behaviors
  6. Compliance – Compliance details the strategies for complying with regulations, contracts, and other established human resource policies.
  7. Safety – Safety procedures are listed to protect the team members.

Pareto Charts are commonly used to identify the source of chronic problems / common causes in a process. The Pareto principal commonly states that 80 % of the trouble comes from 20 % of the problems. A Pareto chart is a graphical technique which quantifies problems in order to position efforts to be expended in fixing the "vital few" causes versus to the trivial many.

The process to create a Pareto Chart or Diagram is as follows:

1. Define the problem and process characteristics to be illustrated in the diagram.
2. Define the period of time analyzed within the diagram. For example, was a month worth of errors analyzed or week's worth.
3. Count the number of times each cause of error occurred.
4. List the causes of error in descending order. Remember the extremely trivial errors are commonly categorized as other, and listed in a legend of the diagram.
5. Find the sum of all errors by adding together the counts of the causes of errors.
6. Calculate the individual percentage for each cause of error.
7. The next step in creating a Pareto chart is to calculate cumulative percentages.
8. Begin drawing a histogram with a numeric scale on the left. Add a bar to the diagram for each category. The height of each bar on the histogram indicates the frequency of errors in each category. Label each bar with the name of the category it represents.
9. Plot a line that shows the cumulative frequency of errors. Draw a scale on the right side of the Pareto diagram to measure cumulative percent. The scale should always range from 0 to 100 percent.
10. The last step, identifying the vital few causes of error, involves completing the histogram by using the cumulative percentages calculated in step 2, and plotting data points to represent the cumulative percentage of each category. Align the data points with the right edge of the corresponding bars. Connect the data points with a line. This completes the Pareto diagram.

The causes of errors that comprise 80% of the errors are vital errors.

Project Human Resource Management includes the processes necessary for organizing and managing the project team. Project Human Resource Management processes are sequential. The outputs of one process are the inputs to the next process. The Project Human Resource Management processes are:

1. Human Resource Planning – Human Resource Planning identifies and declares project team roles, responsibilities, and reporting relationship. Within this process, the project manager will create a Staffing Management Plan. This process occurs within the Planning Process Group.
2. Acquire Project Team - Acquire Project Team is the process of obtaining the project team and orienting them to the project. This process either within the executing process group.
3. Develop Project Team – Developing the project team improves the individuals and groups skill set to enhance project performance. The purpose of this process is not only to develop skills but to also build the team. This process occurs within the Executing Process Group
4. Manage Project Team – Managing the project team is where the appraisals of the team occur along with resolving conflicts, and providing feedback on performance. This process is completed within the Monitoring and Controlling Process Groups

The Quality Control Process engages in monitoring project results to ascertain whether the results conform to the relevant quality standards, and reveals ways to eliminate causes of unacceptable performance. Obviously performing quality control is continuously throughout the project lifecycle.

In order to properly perform quality control, it is good provide the project team with an understanding of the quality control process described in the quality management plan.

The inputs to performing quality control are:

• Quality Management Plan – The quality management plan details how the project team will implement the quality policy.
• Quality Metrics – Quality Metrics are the measurements used to assure the product or service is within the prescribed quality standard.
• Quality Checklists – Quality Checklists are utilized to verify that the required steps have been performed.
• Organizational Process Assets – Organization process assets are the organizations policies, procedures, templates, and standards.
• Work Performance Information – Work performance information is the status on project deliverables, performance measures, and the process on implementing necessary corrective actions.
• Approved Change Request – Approved Change Requests are requested changes which have been approved through the integrated change control process.
• Deliverables – Deliverables are the unique verifiable products or services that are produced and provided by the project.

The tools and techniques for performing quality control can be grouped into three categories: process analysis, data collection, and data analysis. The tools and techniques are:

• Cause and Effect Diagrams - Cause and Effect diagrams graphically illustrate how various factors have the possibility of affecting the outcome.
• Flowcharting – Flowcharting is a graphical presentation of a process. My favorite method is the swim lane diagram.
• Control Charts – Control Charts are a graphical display of the resulting data from a process examined over time against established control limits.
• Histogram – A histogram is a bar chart illustrating the distribution of variables. The height of each column represents the frequency of occurrence.
• Pareto Chart – A Pareto Chart is used to illustrate how many defects are created by categorization. Pareto Diagrams are outcomes of Pareto’s Law where 80 percent of the problems are due to 20 percent of the causes. A key point to remember is that the Pareto Chart has risk inherently built into the chart.
• Run Chart – A Run chart depicts the history and pattern of variation over time. Typically used as a part of trend analysis to monitor either technical performance or cost and schedule performance.
• Scatter Diagram – A scatter diagram portrays the patter of a relationship between two variables. Independent variables are compared to dependent variables. If the points are close to the diagonal line, there is an increased likelihood the variables have a correlation.
• Statistical Sampling – Statistical Sampling selects a part of the population of interest for inspection.
• Inspection – An inspection is the examination of the deliverable product to ascertain whether it conforms to standards. For example code reviews are a form of inspection.
• Defect Repair Review – Defect Repair review is the validation that the defect has been corrected and now the result conforms to quality standards.

The outputs from the Perform Quality Control process document the outcomes of quality control activities and provide a basis for improvements. The outputs are:

• Quality Control Measurements – Quality control measurements are the results which are submitted to quality assurance to reassess and evaluated the organization quality standards.
• Validated Defect Repair – Validated Defect Repair are the accepted or repaired defects.
• Quality Baseline Updates – Quality Baseline updates document the current quality objectives of the project.
• Recommended Corrective Actions – Recommended Corrective Actions are actions needed to bring the project back inline with the plan.
• Recommended Preventative Actions – Recommended Preventative Actions are actions needed to mitigate a possible risk to the project.
• Requested Changes – Requested changes are change requests which need to go through integrated changed control.
• Recommended Defect Repair – A defect which does not meet the quality requirements is submitted for repair.
• Organizational Process Assets – The organizational processes are updated with the completed checklists and lessons learned documentation.
• Validated Deliverables – Validated deliverables are the verified deliverables which have been through the quality control process.
• Project Management Plan Updates – Project Management plan updates are typically any approved change to the quality management plan from performing the quality control process.

Quality assurance is the execution of planned, systematic quality activities to assure the project will take advantage of all processes necessary so the product, application or service meets customer requirements. An aspect of quality assurance is continuous process improvement which entails using an iterative process for improving the quality of all processes. The goal of continuous process improvement is to reduce waste and non-value added activities allowing processes to operate at an increased level of efficiency and effectiveness.
The inputs to performing quality assurance incorporate information from project plans, project performance, and project changes. This information provides a basis for performing the quality-related activities that lead to continuous improvement. The inputs are:

• Quality Management Plan - The Quality Management Plan describes how the team will implement the performing organization's quality policy. The Quality Management Plan is the plan on validating previous design decisions. For example the database schema will be reviewed by colleagues from the DBA department and development to assure it of third normal form. This is a peer review.
• Process Improvement Plan - The Process Improvement Plan lists the steps for analyzing processes that expedite the identification of ineffective wasteful process or non-value added activities.
• Quality Metrics - Quality metrics describe the specific attributes of the project work that will be measured to determine whether the work meets quality standards. Quality metrics are used to provide information on cost, rework, and cycle time to improve the quality of the project deliverables and work processes
• Work Performance Information – Work performance information are the technical performance measures (CPI, SPI), project deliverables status, required corrective actions, and performance reports.
• Approved Change Requests – Approved change requests are modifications to scope, cost, time or quality which have been approved through the integrated change control process.
• Quality Control Measurements – Quality Control Measurements are the outputs of Quality control that may be used to evaluate and analyze the current quality standards.
• Implemented Change Requests – Implemented Change requested are approved change requests which have been executed and implemented.
• Implemented Corrective Actions – Implemented Corrective Actions are approved corrective actions to bring project performance back in line with anticipated performance which have been implemented as a part of project execution.
• Implemented Defect Repair – Implemented Defect Repairs are approved defected repairs to the product, application or service back in line with expect quality standards.
• Implemented Preventative Actions – Implemented Preventative Actions are approved preventative actions to mitigate risk to a project’s performance.

The tools and techniques for the Perform Quality Assurance process give performing organizations the tools they need to achieve quality results while reducing costs. The tools and techniques for the Quality Assurance Process are:

• Quality Planning Tools and Techniques - there are some common tools and techniques which project managers employ during the process. For example:
  1. Cost-benefit analysis - A cost-benefit analysis evaluates the cost-benefit tradeoffs for making a potential change.
  2. Design of experiments (DOE) – Design of experiments is a statistical method which identifies influencing factors of the product or process being created. This technique provides a way to change all of the influencing factors at once instead of on a factor by factor basis.
  3. Benchmarking – Benchmarking engages in comparing projects as a basis to measure performance.
  4. Costs of Quality (COQ) – Costs of Quality are the total costs incurred by investing in preventing nonconformance to requirements, appraising the conformance to requirements, and failing to meet the requirements.
  5. Affinity diagramming – The affinity diagram helps to categorize brainstorming ideas.
  6. Force field analysis – Force field analysis examines and evaluates all the forces for and against a decision. Project managers use this method to weigh the pros and cons of a decision.
  7. Nominal group techniques – Nominal group techniques are structured procedures that identify and rank major problems or key issues that need to be addressed. Project managers may use this method to obtain multiple ideas from team members on a particular problem or issue.
  8. Matrix diagrams – Matrix diagrams are used to compare the efficiency and effectiveness of alternatives based on the relationship between two criteria. A project manager can use a matrix diagram to analyze the relationship between project cost and project performance.
  9. Flowcharts - Flowcharts are graphical representations of a process. A flowchart allows a project team to create a diagram of the events in a process. By examining flowcharts carefully, the project team can often identify gaps in workflow that could cause problems and errors.
• Quality Audits – A quality audit is a structured, independent review which ascertains if the project is complying with prescribed policies, processes, and procedures. The purpose of a quality audit is to identify inefficient and ineffective policies, processes, and procedures in use on the project.
• Process Analysis – Process analysis examines problems and constraints experienced and non-value added activities identified within a process. After performing a root cause analysis, the improvements are implemented and a control monitor is placed to assure the process has been improved.
• Quality Control Tools and Techniques – The Quality Control Tools and Techniques are the Seven Basic Tools of Quality.

Remember Quality Assurance is repeated throughout project execution. The outputs from the Perform Quality Assurance process provide a way to turn the findings of quality assurance activities into actions that improve the organization's ability to meet quality requirements. After performing quality assurance, one will have the resulting outputs:

• Requested Changes - Requested changes are proposed alterations to the performing organization's policies, processes, or procedures.
• Recommended Corrective Actions - Recommended corrective actions correct the results of work activities that weren't performed according to required procedures, and they bring performance into compliance with planned quality standards. These are reactive actions taken to address the findings of quality audits or process analysis.
• Organizational Process Asset Updates – Organizational Process Asset Updates update the set of quality standards the organization applies to standard processes.
• Project Management Plan Updates - As an organization executes a Quality Management Plan, it sometimes discovers that the plan needs to be modified. Since the Quality Management Plan is a subsidiary plan of the Project Management Plan, updates to the Quality Management Plan are updates to the Project Management Plan

Quality planning is the process which identifies which quality standards are important to the project and determines a way to satisfy the relevant standards. Project managers normally develop the quality requirement as a part of the Planning Process Group.

The inputs to the quality planning process are:

• Enterprise environmental factors - Enterprise environmental factors are any or all external environmental and internal organizational influences on a projects success. The purpose of inputting enterprise environmental factors into the quality planning process is to assure your plan is cognizant of the bigger picture.
• Organizational process assets - Organizational process assets are any process-related assets which can influence the projects outcome. Assets commonly include informal or formal quality policies, guidelines, and procedures, as well as historical databases related to quality.
• Project Scope Statement - The Project Scope Statement describes the major deliverables, acceptance criteria for the deliverables, objectives, assumptions, constraints, and a statement of work for the project. The Project Scope Statement provides a basis for making future project decisions. Project Managers commonly plan project activities so that the project deliverables meet the desired level of quality.
• Project Management Plan - The Project Management Plan defines how the project is expected to behave through the executing, monitoring and controlling, and closing process groups. In addition, it specifies that a quality plan and philosophy will be adopted, and it refers to other quality procedures that may be relevant. The Project Management Plan details the completed project work to be inspected and verified.

While engaged in Quality Planning, there are some common tools and techniques which project managers employ during the process. Quality Planning can be completed using the following tools and techniques:

• Cost-benefit analysis - A cost-benefit analysis evaluates the cost-benefit tradeoffs for making a potential change. Since quality planning is the art of considering tradeoffs, project managers use cost-benefit analysis to determine the cost-effectiveness of assuring product quality.
  The steps to perform a cost-benefit analysis are:
  1. List and calculate the direct and indirect costs.
  2. List and Calculate the Benefits.
  3. Compare the resulting Costs to Costs and Benefits to Benefits.
  
  Direct costs are the estimated financial costs from budget making and planning including expenses from equipment, operators, personnel, training, materials, utilities, contractual services, and facility construction. Indirect cost estimate shared resources including infrastructure maintenance, administration expenses, and safety costs.
• Design of experiments (DOE) – Design of experiments is a statistical method which identifies influencing factors of the product or process being created. This technique provides a way to change all of the influencing factors at once instead of on a factor by factor basis.
• Benchmarking – Benchmarking engages in comparing projects as a basis to measure performance.
• Costs of Quality (COQ) – Costs of Quality are the total costs incurred by investing in preventing nonconformance to requirements, appraising the conformance to requirements, and failing to meet the requirements.
• Additional Quality Planning tools - Additional Quality Planning tools which help project and quality managers are as follows:
  1. Affinity diagramming – The affinity diagram helps to categorize brainstorming ideas.
  2. Force field analysis – Force field analysis examines and evaluates all the forces for and against a decision. Project managers use this method to weigh the pros and cons of a decision.
  3. Nominal group techniques – Nominal group techniques are structured procedures that identify and rank major problems or key issues that need to be addressed. Project managers may use this method to obtain multiple ideas from team members on a particular problem or issue.
  4. Matrix diagrams – Matrix diagrams are used to compare the efficiency and effectiveness of alternatives based on the relationship between two criteria. A project manager can use a matrix diagram to analyze the relationship between project cost and project performance.
  5. Flowcharts - Flowcharts are graphical representations of a process. A flowchart allows a project team to create a diagram of the events in a process. By examining flowcharts carefully, the project team can often identify gaps in workflow that could cause problems and errors.

You can increase your chances of achieving quality in a product by understanding the Quality Planning outputs. The Quality Planning outputs are:

• Quality Management Plan - The Quality Management Plan describes how the team will implement the performing organization's quality policy. The Quality Management Plan should include a way to assure the previous design decisions are valid perhaps through a peer review.
• Process Improvement Plan - The Process Improvement Plan lists the steps for analyzing processes that expedite the identification of ineffective wasteful process or non-value added activities. The components of the process improvement plan are:
  1. Process Boundaries – Process boundaries detail the purpose, start and end of the process, inputs and outputs, data needed, and the owner and stakeholders of the process
  2. Process Configuration – Process Configuration is a flowcharts o the process which assist with analysis of the interfaces detailed.
  3. Process Metrics - Process Metrics are to provide a guideline of control over the status of a process.
  4. Targets for improved performance – Targets for improved performance guides the process improvement activities.
• Project Management Plan updates - Project Management Plan updates result from Quality Planning. Specifically, the Project Management Plan will be updated because you will have developed two of its subsidiary plans: the Quality Management Plan and the Process Improvement Plan.
• Quality checklists - Quality checklists are used to validate that all the steps of a process are complete and that all the components of a deliverable are in place. Using checklists ensures that deliverables are consistent and contain all the necessary information.
• Quality baseline - A quality baseline records the project's quality objectives. The quality baseline establishes the acceptable quality levels by which project deliverables are measured.
• Quality metrics - Quality metrics describe the specific attributes of the project work that will be measured to determine whether the work meets quality standards. Quality metrics are used to provide information on cost, rework, and cycle time to improve the quality of the project deliverables and work processes. Examples of quality metrics include defect density, failure rate, availability, reliability, and test coverage.

Project Quality Management is all about the synergy of continuous improvement of the project and the principal of project delivery. Using a Quality Management approach play a key role in assuring the project meets the customer requirements.
The three processes associated with Project Quality Management are:

1. Quality Planning – Quality planning identifies the standards which are relevant to the project and how to assure the standards are achieved. This is a key process of the planning process group.
2. Perform Quality Assurance – Performing Quality Assurance is the execution of the quality activities during project execution.
3. Perform Quality Control – Performing Quality Control is the monitoring deliverables to evaluate whether they comply with the project’s quality standards and to identify how to permanently remove causes of unsatisfactory performance. This process occurs as a part of the monitoring and controlling process group.

Quality management from a project perspective is to assure that the stakeholder requirements detailed within the Project Scope Document are met. Quality Management is concerned with and about the importance of:

• Customer Satisfaction – Customer satisfaction is the understanding, evaluation, definition, and management of expectations so that customer requirements are met. This approach requires conformance to requirements and a fitness of use for the product or service.
• Prevention over inspection – Prevention over inspection is the common sense principal that the cost of preventing mistakes is generally much less than the cost of correcting them. (Especially when they are uncovered during an inspection)
• Management responsibility – Management responsibility in quality is to provide the resources needed to sustain success.
• Continuous improvement – Continuous improve is following the plan-do-check-act cycle of quality improvement.

There are a couple of costs of quality one needs to be familiar with from a quality management perspective for managing project. Those are:

• Cost of Quality (COQ) – Cost of quality refers to the total cost of all efforts related to quality. The appraisal, prevention, and failure costs are included in this term.
• Cost of Poor Quality (COPQ) – Cost of poor quality addresses the cost of not performing work correctly the first time or not meeting customer’s expectations
• Cost of Doing Nothing Different (CODND) – Cost of Doing Nothing Different is the cost of not changing standard practice, even when it is dysfunctional.

Controlling Cost in a project is the only way to assure the within budget part of a successful project. Cost control involves being diligent of about requested changes and handling those changes through the integrated change control process. A change request can vary between a potential overrun of authorized funding to inappropriate resource usage.

As with all things PMI, there are inputs, tools and techniques, and outputs of cost control.
The inputs are:

• Performance reports – Performance reports provide the actual costs and resource usage based upon completed work. Performance reports yield information on work progress, some common formats are the bar chart, S-curves, histograms, table, and network diagrams which illustrate the current schedule status.
• Approved change requests – An approved change request is one that has been successfully through the Integrated Change Control process and given the stamp of approval.
• Cost Baseline – The cost baseline is a time-phased budget. The purpose of the cost baseline is to provide a basis against which to measure, monitor, and control the overall project’s cost performance.
• Project funding requirements – Project funding requirements are based upon the cost baseline and contingency reserves. Let’s say that a task is running late and there is a change request to add another resource. A PM may look at the baseline and contingency reserves to determine the money is available.
• Project Management Plan - The Project Management Plan and its subsidiary cost management plan details the organizational policies and procedures which need to be followed.
• Work performance information – Work performance information contains the current status on deliverables, costs, and the schedule.

There are common tools and techniques which PMs use to control costs. They are:

• Cost change control system – The cost change control system is a component of integrated change control. Defined in the cost management plan, the change control system lists how cost changes are handled and what is needed to handle these changes.
• Performance measurement analysis – Performance measurement analysis is the usage of the earned value techniques to identify variances and determine if corrective action is needed.
• Forecasting – Forecast is how estimates or prediction of the project’s future are made. This process includes the calculation of EAC, BAC, and ETC.
• Project performance reviews – Project performance reviews compare the activity costs over time, scheduled activities, and milestone progress.
• Project management software – PMIS can be utilized to track costs and forecast the effect of changes on estimated costs. This information can be used to support suggested changes.
• Variance management – Variance management illustrates the varying degrees of variances should be managed. The various management techniques to use on a project are commonly found in the Cost Management Plan. Ideally there is a different way of handling small variances to large variances.

So after engaging in the cost control process, what are the end results? The outputs of controlling cost are:

• Cost estimate updates – Cost estimate updates are approved changes that result in an update to the project documents which depict cost information – normally the activity cost estimate document.
• Recommended corrective actions – Recommended corrective actions are steps which should be by the project management team to ensure that any future work supports the current Project Management Plan.
• Forecasted completion – Forecasted completion is the calculated estimate at completion or the estimate to completion. This value is communicated to the stakeholders and sponsors.
• Requested changes – Request changes are normally resulting from the recommended corrective actions.
• Organizational process assets updates – Organizational process updates are the enhancement added to the organizational process documents. For example, lessons learned on why a schedule variance occurred and how it was resolved.
• Performance measurements – Performance measurement are the calculated earned values used to monitor project cost performance. Typically the CV, CPI. SV, and SPI.
• Cost baseline updates – Cost baseline updates are approved changes to the current cost baseline. By updating the baseline one can use it as a realistic measure against which project cost performance can be judged.
• Project Management Plan updates – Project Management Plan updates encompass any approved changes to the project management plan or any subsidiary management plans.

A key point is that one measure a pm can take to assure a successful project is to control the costs of that project.

Cost Budgeting is the process of establishing a budget for the project. This is normally completed by summarizing the estimated costs of the work packages in order to establish a cost baseline. The cost baseline will help to assure that costs are appropriately allocated and distributed by managing changes and variances which affect project costs. The inputs to the cost budgeting process are:

• Project Scope Statement – The project scope statement will normally detail any limitations on budgets or due to contracting conditions.
• Work Breakdown Structure – The WBS details the dependencies between project activities and deliverables.
• WBS dictionary - The WBS dictionary lists the detail information for the work which needs to be completed to construct the project deliverables.
• Project Schedule - The Project Schedule provides the expected dates for specific activities and milestones.
• Activity cost estimates - Activity cost estimates help establish a cost baseline because they provide the cost estimate for each of the expected schedule activities including the resource cost for staff, equipment and materials.
• Activity cost estimate supporting detail - The supporting detail illustrates how the cost estimate was created and includes a description of the activity's scope of work, as well as any assumptions and constraints. It may also include a range of estimates that indicate the expected cost of an item.
• Resource calendars - Resource calendar help to establish when a resource is being utilized. The calendar shows holidays and the days that resources are available, as well as the quantity of each available resource. Sometimes a resource calendar even describes when and how resource costs will be incurred.
• Contract - The contract provides cost information on the resources purchased for the project. Larger projects may have more than one supplier, resulting in multiple contracts.
• Cost Management Plan – The cost management plan provides information about internal organizational processes and procedures that should be considered during Cost Budgeting. For instance, an organization may require that its project managers submit budgets to the financial manager for final signoff.

Once you have the inputs at a convenient place, and have a good understanding of the content provided, there are several tools and techniques which can help a pm create a realistic cost baseline. These tools are:

• Cost aggregation - Cost aggregation is utilized to determine total costs for deliverables and for an entire project. The final sum of the cost estimates is applied as the cost baseline.
  The steps to perform aggregation are the following:
  1. First detail the cost estimate to the work packages at the lowest level of the WBS.
  2. Next, Total the costs for all the activities belonging within the work package. Then summarize up to the next level. Repeat this process for each level in the WBS.
  3. Next, Calculate the Contingency Reserves if applicable
  4. Identify the dates for the cost baseline based on the project schedule.
• Reserve analysis - Contingency reserves are amounts of money set aside for unplanned changes to costs; they are part of the total budget, but they are not part of the cost baseline. The total budget is the approved cost estimate for the entire project. The cost baseline is a tool project managers use to monitor and control project expenditures.
• Parametric estimating - Parametric estimating is a technique that uses a statistical relationship between historical data and other variables to calculate an estimate.
• Funding limit reconciliation - Project managers use funding limit reconciliation to avoid large variations in the periodic expenditure of project funds. They do this by reconciling project expenditures with the funding limits set by the customer. Reconciliation may require the revision of project schedules to regulate expenditures; this in turn affects the allocation of resources.

Cost baselines enlighten project managers of the difference between current costs and what is estimated for future activities. A cost baseline also helps identify possible issues regarding current and future costs when expectations change.
The outputs from Cost Budgeting are:

• Cost baseline – The cost baseline illustrates estimated costs with the due dates for the work packages that incur the costs. It is used to monitor and control cost performance.
• Requested changes – Obviously requested changes will be requested as the project progresses.
• Project funding requirements - These requirements are conditions that account for the possibility that actual costs may exceed the estimated costs during different time frames.
• Cost Management Plan updates – The cost management plan needs to be updated with approved changes which may affect how costs are managed within the project.

As previously mentioned, cost estimating is the process of developing an estimated cost for the resources needed to complete project activities. Cost Estimating normally occurs in the planning process group and is dependent on several of the outputs from the Initiating and Planning Process groups.
The inputs to cost estimating are:

• The Project Scope Statement - This is a narrative description of the project scope, including major deliverables, scope objectives, scope assumptions, scope constraints, and a Statement of Work. The deliverables, acceptance criteria, and the project's products and services are be taken into account in the project scope statement.
• Work Breakdown Structure – The WBS is a hierarchical decomposition of the anticipated work that is required to complete the project objectives and create the necessary deliverables.
• The WBS dictionary – The WBS dictionary details each component in the wbs with an estimated cost, a brief definition of the scope of work, defined deliverable, a list of activities, and a list of milestones.
• The Project Management Plan – The Project Management Plan is is the key document that contains the overall planning, monitoring, and implementing activities to be done in a project. Several subsidiary plans are used in cost estimating. They are:
  1. The Schedule Management Plan – The schedule management plan details the project activity list, activity list attributes, estimated activity resources, and activity duration estimates. The document illustrates the type and quantity of resources and when they are needed to completed the project work.
  2. The Staffing Management Plan – The staffing management plan describes how and when resource requirements will be achieved. It also explains how resources can be removed from or added to a project.
  3. The Risk Register – The risk register contains the results of the risk analyses, risk prioritization and planned risk responses. It details all of the identified risks, including the description, category, cause, probability of occurrence, effect on objectives, proposed responses, owner, and current status.
  
  
• Enterprise environmental factors – Enterprise environmental factors are the external and internal influences and constraints that may affect a project’s success. This includes organizational culture and structure, infrastructure, existing resources, commercial databases, market conditions, and PMIS.
• Organizational Process Assets – Organizational Process Assets are all formal and informal plans, policies, procedures, and guidelines. All of the process documents that can be used to influence a project’s success.

These inputs are very useful in helping to ascertain estimated costs; there are also a number of tools and techniques that can be used to help identify estimated costs. These tools and techniques are:

• Analogous cost estimating – Analogous cost estimating is the process of comparing historical information to forecast the cost of the current project. This approach is common when there is little information about the project.
• Determining resources cost rates – Determining resource cost rates details the resource rate as a unit rate for each resource. One way to do this is to collect quotes from suppliers.
• Bottom-up estimating – Bottom-up estimating identifies and estimates each activity and then summarizes the results to product a project estimate. A bottom up estimate usually involves three steps.
  1. Estimate the cost of each activity that composes the work package. Estimate the cost of each task by adding the labor and material costs; then add the estimated costs of each task, including contingency and cost of quality, to get an activity cost estimate.
  2. Roll up those estimates by totaling the estimates at each level of the WBS. You may use exact figures or rounded numbers, according to the rules of your organization.
  3. Calculate an overall project estimate. This estimate is the cost rolled up to the top level, or the sum of all the items at the level below it.
• Parametric estimating – Parametric estimating bases a parameter into calculate cost commonly used with historical data and other factors. For example, if last time it cost $500 to install 10 network jacks, this time we have 5 network jacks, so it should cost $250.
• Project management software – PMIS is the software used for managing the project. Several PMIS tools have modules for estimating cost as well as simulating alternative mechanisms.
• Vendor bid analysis – In a competitive bid process, you can apply vendor bid analysis to determine how much a project should cost. Comparing bids can help you determine the most likely cost for each deliverable, which will allow for a more accurate project cost estimate.
• Reserve analysis – Reserve Analysis is an analytical technique to determine the essential features and relationships of components in the Project Management Plan to establish a reserve for the schedule duration, budget, estimated cost, or funds for a project.
• Cost of quality – Cost of quality are the prevention costs, appraisal costs, internal failure costs, and external failure costs that come with quality planning, control, and assurance.

Remember estimating begets funding, so it is necessary that you estimating cost as exactly as possible with a contingency reserve. When you have completed the cost estimating process you should have the following outputs:

• Activity cost estimates – The activity cost estimates comprise the quantitative valuation of the probable costs of the resources necessary for carrying out project activities. This should be presented against the Work Breakdown Structure components, or summarized in terms of totals by project phases or major deliverables. Activity cost estimates include the labor costs, material costs, services, equipment, and special categories.
• Activity cost estimate supporting detail – The supporting detail represents a logical and comprehensive explanation for how the cost estimates were derived. Very useful to have when explaining costs to business cases.
• Requested changes - These changes are likely to have an effect on the cost components of the Project Management Plan.
• Cost Management Plan update – Approved changes from the Cost Estimating process will cause an update to the Cost Management Plan reflecting the changes with an effect on the management of costs.

The cost management processes are all about the cost of the resources necessary to complete the project activities. The three processes in the Project Cost Management knowledge area are:

1. Cost Estimating – Cost Estimating is the process of developing an estimated cost for the resources needed to complete project activities. Cost Estimating normally occurs in the planning process group.
2. Cost Budgeting – Cost Budgeting is the process of summarizing the estimated costs of individual activities or work packages to establish a cost baseline. Cost Budgeting normally occurs in the planning process group.
3. Cost Control – Cost Control is how the cost variances and other changes to the project are managed and controlled. Cost Control occurs in the monitoring and controlling process group.

So how does one go about cost planning? Cost Planning activities should occur prior to engaging in estimating and budgeting cost. In order to plan a couple of agreements in how to qualify and quantify cost are necessary, those agreements are:

• A determination of the precision level for schedule activity cost estimates - Schedule activity cost estimates will comply with a rounding of the data to a predetermined precision based on the size of the project and the scope of the activity. (Remember that contingencies may be factored in here.)
• Establishment of a unit of measure for each of the resources – During estimation, it is necessary for the project management team to agree on a standard unit of measure for each resource. For example, the unit of measure for a particular task may be staff-days or staff-weeks.
• Establishment of direct tie ins to organizational procedures - A control account is normally established to control project cost accounting. Individual control accounts are given a code or an account number that is directly linked to your general ledger account system.
• Definition of control thresholds - Planning items for controlling costs should include control thresholds for costs. For example, if a threshold for a given activity is set at $5,000, the project manager must be alerted before the costs exceed this amount.
• Definition of earned value rules – The Earned Value Formulas for computing earned value which determine the estimate to complete are identified.
• Development of the formats for the various cost reports – Standardized reporting formats are established by the Cost Management Plan. Reports are provided to the stakeholders. It is good to use an organizational template here.
• Documentation of each of the three Project Cost Management processes - The three cost management processes should be documented in the Project Management Plan as they relate to the specific project.

The purpose of planning activities is to increase the efficiency and effectiveness in how an organization and project manager manage project costs.

An ever enjoyable aspect of managing a project is the control the project schedule. The managing and maintaining the schedule proactively is your best way to assure the project comes in on time.
In order to be proactive about this process there are some inputs that one needs to understand. The inputs are:

• The Schedule Baseline - The schedule baseline is the current approved version of the project schedule which provides a basis for comparing and reporting on the project performance. The project schedule details the planned start and end dates for the activities.
• Performance Reports – Performance reports are first and foremost a communication mechanism to list what work has been performed by whom. A good performance report should show the planned and actual dates and duration of work activities
• Schedule Management Plan – The Schedule Management Plan details how changes to the schedule can be made and under which conditions such changes are allowed. Project Manager, Project Sponsors, and Functional Managers should adhere to the scheduling guidelines explained within the schedule management plan.
• Approved Change Requests - Approved schedule change requests are an input because the schedule needs to be revise to reflect the approved changes to the project schedule.

Once all of the inputs have been obtained, there are tools and techniques that can be used to review the schedule. If a situation occurs where project performance differs from the schedule, these tools and techniques can be used to correct the situation. Project managers will evaluate how much work has been completed compared with actual performance versus planned performance. If they uncover a schedule variance, the pm should analyze the variance’s severity.

The tools and techniques commonly employed in controlling the schedule are:

• Progress reporting – Progress Reporting is when a report is created detailing the actual start and finish dates of activities and the remaining duration of unfinished activities. It is a good idea to include the percent complete of activities in the progress report.
• Variance Analysis – Variance analysis compares planning data with actual performance in order to discover delays or variations in the project schedule. For example the planned start, duration, and anticipated completion date would be compared with the actual start date, duration, and completion date for that activity.
• Performance Measurement - Performance measurement assesses the severity of delays and other deviations by measuring project performance compared against the project plan. This comparison helps the project manager determine if corrective or proactive actions are need for this project. Some common performance measurement tools are:
  • Schedule comparison bar charts – Schedule comparison bar charts are a way to visualize the differences between the planned and actual performance. This is a good tool to graphically communicate project status.
  • Project Management Software – PMIS is utilized to determine the affect of variance upon individual activities. The PMIS easily calculates the impact of any proposed change to the schedule.
  • Schedule change control systems – Schedule change control systems are described in the project management plan with the integrated change control process. The schedule change control system is the bought into, agreed with, and realistic process to change the schedule. When project managers discover that actual performance is not meeting the schedule, it is a good idea to use the schedule change management process to propose changes to the schedule
  • Schedule variance and the Schedule Performance Index - Schedule variance and the Schedule Performance Index both measure the financial value of the work performed as of a given date.
    SV = EV – PV
    SPI = EV / PV
    Schedule variance and the Schedule Performance Index yield information on the current conditions of the project and can be used to determine whether the project is on or off schedule.

The process of controlling the schedule creates several different types of outputs as follows:

• Performance measurements - The process of controlling the schedule produces measurements of performance to date on a project. The Schedule Variance and Schedule Performance Index are objective measures of project performance that can be used to report the status of the project to stakeholders.
• Requested changes – Requested changes are the proposed changes to start dates, finish dates, activity durations, or project milestones.
• Recommended corrective actions – Recommended corrective actions are changes to resolve a situation with the project schedule.
• Schedule Baseline updates – Schedule Baseline updates are done when approved changes are applied to the existing baseline.
• Schedule Model data updates – Schedule model data updates are updates to the alternative best-case or worst-case schedules, cash flow projections, order schedules, delivery schedules, and other information about schedule constraints and assumptions. The changes must be documented and communicated to project stakeholders.
• Activity List updates – Activity List updates occur when an approved change causes the project manager to add or remove activities from the Activity List.
• Activity attribute updates – Activity attribute updates are updates or changes in the description or relationship of project activities. These changes may require additional actions by some stakeholders, so they have to be communicated.
• Organizational process assets - Detecting a schedule variance and finding a solution provide valuable lessons for future projects. These lessons are documented and kept. They can be shared with others in the organization who executed the project.
• Project Management Plan - Finally, the process of controlling the schedule may generate changes to the overall Project Management Plan. Corrective actions and approved schedule changes may call for changes in the methods, policies, and activities the project manager uses to control the schedule for the remainder of the project. These changes should be documented in the Schedule Management Plan segment of the Project Management Plan.

When project managers control the Project Schedule, they make decisions that alter the project. Outputs from controlling the schedule connect the decisions with actions.

Stage	Description
Forming	At this stage, team members are wondering whether the decision to join the team was a wise one. The team is making inital judgements about the skills and personal qualities of their teammates, as well as worrying about how they will be individually will be viewed by the rest of the team. During this stage, team conversations tend to be polite and noncommittal, as people hesitate to reveal too much about their personal views. In addition, team meetings tend to be confusing, as the team goes throught the growing process to determine who is in command.
Storming	At this stage, the team members begin to assert themselves and control issues emerge. Personality differences begin to arise. Conflicts are resulting from team members differing on the way they want to do the project work, or the way they want to make decisions.
Norming	At this stage, the team starts to work productively, without concern about personal acceptance or control. There are still conflicts but they are normally around process issues. The team is at the starting point to operate off of dependence and trust.
Performing	At the performing stage, the team is working at optimum productivity. Team members collaborate and communicate freely. They solve their own conflict problems. The level of trust between team members make everyone feel trusting and teammates help each other out, finding the best solution for the team as a whole.

Earned Value Management is a way to measure a project's performance against the project baseline. An earned value analysis can clue the project manager into trending deviations from the project's cost and schedule plans. Earned Value Management integrates cost, time, and scope completed. It is very useful in forecasting future performance.

The Terminology

Acronym	Term	Description
PV	Planned Value	PV is the authorized budget assigned to the scheduled work to be accomplished for a scheduled activity or work breakdown structure component.
EV	Earned Value	EV is the value of completed work expressed in terms of the approved budget assigned to that work for a scheduled activity or work breakdown structure component. The cumulative EV is the sum of the approved budgets for activities completed during a given period.
AC	Actual Cost	AC is the total costs incurred and recorded in accomplishing work performed during a given time period for a scheduled activity or work breakdown structure component. Actual cost can sometimes be direct labor hours alone; direct costs alone; or all costs, including indirect costs
BAC	Budget at Completion	BAC is the total amount of funds to be spent at the completion of the task.
EAC	Estimate at Completion	EAC is used by project managers to give their best estimate of the total costs of projects based on actual costs to date. The most frequently used formula for EAC is AC plus ETC; this formula is typically used when previous assumptions regarding costs are wrong.
ETC	Estimate to Complete	ETC is the expected cost needed to complete all the remaining work for a scheduled activity, a group of activities, or the project. ETC helps project managers predict what the final cost of the project will be upon completion.
VAC	Variance at Completion	VAC forecasts the difference between the Budget-at-Completion and the expected total costs to be accrued over the life of the project based on current trends.

The Formulas

Acronym	Term	Formula	Description
CV	Cost Variance	CV = EV - AC	CV provides the cost performance of the project to help determine whether the project is proceeding as planned. Subtracting AC from EV calculates the cost variance.
SV	Schedule Variance	SV = EV - PV