Send Us Feedback


Questions, comments, suggestions? Let us know what you think on our User Forum.

To contact us privately, please use our contact form.

Author: Elyse, PMP, CPHIMS
March 12, 2011

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.

Author: Elyse, PMP, CPHIMS
February 12, 2011

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.


Author: Elyse, PMP, CPHIMS
May 31, 2010

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"

Author: Elyse, PMP, CPHIMS
May 26, 2010

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.

Author: Elyse, PMP, CPHIMS
May 22, 2010

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.

Author: Elyse, PMP, CPHIMS
April 8, 2010

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:



Author: Elyse, PMP, CPHIMS
March 26, 2010

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:



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:

Author: Elyse, PMP, CPHIMS
March 20, 2010

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.

Author: Elyse, PMP, CPHIMS
March 12, 2010

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.

Author: Elyse, PMP, CPHIMS
February 2, 2010

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!


Author: Elyse, PMP, CPHIMS
December 29, 2009


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


Author: Elyse, PMP, CPHIMS
November 27, 2009

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:



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:



Author: Elyse, PMP, CPHIMS
October 25, 2009

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:



Author: Elyse, PMP, CPHIMS
October 16, 2009

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:

Author: Elyse, PMP, CPHIMS
October 13, 2009

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:

Author: Elyse, PMP, CPHIMS
September 26, 2009

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:



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:



Author: Elyse, PMP, CPHIMS
September 19, 2009

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"

Author: Elyse, PMP, CPHIMS
August 20, 2009

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:


Author: Elyse, PMP, CPHIMS
May 31, 2009

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: Good Luck in your pursuits! If you are interested in reading a little further on project management, please check out:

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. Relative Scope Change Costs Further Readings

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?


Author: Elyse, PMP, CPHIMS
May 20, 2009

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:


Author: Elyse, PMP, CPHIMS
May 19, 2009

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.


Author: Elyse, PMP, CPHIMS
May 15, 2009

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.


Author: Elyse, PMP, CPHIMS
April 14, 2009

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.


Author: Elyse, PMP, CPHIMS
December 18, 2008

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:


Author: Elyse, PMP, CPHIMS
September 3, 2008

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.


Author: Elyse, PMP, CPHIMS
August 17, 2008

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.


Author: Elyse, PMP, CPHIMS
August 15, 2008

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.


Author: Elyse, PMP, CPHIMS
August 11, 2008

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.


Author: Elyse, PMP, CPHIMS
July 28, 2008

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.


Author: Elyse, PMP, CPHIMS
February 23, 2008

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.

Author: Elyse, PMP, CPHIMS
February 11, 2008

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.


Author: Elyse, PMP, CPHIMS
February 6, 2008

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.



Author: Elyse, PMP, CPHIMS
February 3, 2008

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.



Author: Elyse, PMP, CPHIMS
January 15, 2008

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


Author: Elyse, PMP, CPHIMS
November 18, 2007

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.


Author: Elyse, PMP, CPHIMS
October 2, 2007

"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.


Author: Elyse, PMP, CPHIMS
September 11, 2007

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.

Author: Elyse, PMP, CPHIMS
September 9, 2007

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.


Author: Elyse, PMP, CPHIMS
September 8, 2007

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.


Author: Elyse, PMP, CPHIMS
August 31, 2007

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.


Author: Elyse, PMP, CPHIMS
August 24, 2007

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.


Author: Elyse, PMP, CPHIMS
June 7, 2007

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.



Author: Elyse, PMP, CPHIMS
May 29, 2007

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.


Author: Elyse, PMP, CPHIMS
April 26, 2007

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.


Author: Elyse, PMP, CPHIMS
April 25, 2007

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


Author: Elyse, PMP, CPHIMS
April 4, 2007

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.


Author: Elyse, PMP, CPHIMS
April 2, 2007

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.


Author: Elyse, PMP, CPHIMS
March 29, 2007

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.



Author: Elyse, PMP, CPHIMS
February 20, 2007

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.



Author: Elyse, PMP, CPHIMS
February 11, 2007

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.


Author: Elyse, PMP, CPHIMS
February 7, 2007

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:



Author: Elyse, PMP, CPHIMS
February 6, 2007

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:

Author: Elyse, PMP, CPHIMS
February 6, 2007

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

Author: Elyse, PMP, CPHIMS
February 5, 2007

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).

RSB.jpg

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.


Author: Elyse, PMP, CPHIMS
February 5, 2007

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.


Author: Elyse, PMP, CPHIMS
January 30, 2007

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.


Author: Elyse, PMP, CPHIMS
January 30, 2007

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.


Author: Elyse, PMP, CPHIMS
January 29, 2007

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.


Author: Elyse, PMP, CPHIMS
January 27, 2007

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.


Author: Elyse, PMP, CPHIMS
December 28, 2006

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:



Author: Elyse, PMP, CPHIMS
December 27, 2006

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.


Author: Elyse, PMP, CPHIMS
December 27, 2006

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.


Author: Elyse, PMP, CPHIMS
December 26, 2006

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.


Author: Elyse, PMP, CPHIMS
December 26, 2006

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.


Author: Elyse, PMP, CPHIMS
December 24, 2006

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?


Author: Elyse, PMP, CPHIMS
December 23, 2006

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.


Author: Elyse, PMP, CPHIMS
December 22, 2006

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.


Author: Elyse, PMP, CPHIMS
December 22, 2006

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.

Author: Elyse, PMP, CPHIMS
December 21, 2006

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.


Author: Elyse, PMP, CPHIMS
December 20, 2006

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.


Author: Elyse, PMP, CPHIMS
December 19, 2006

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.


Author: Elyse, PMP, CPHIMS
December 18, 2006

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


Author: Elyse, PMP, CPHIMS
December 17, 2006

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.


Author: Elyse, PMP, CPHIMS
December 16, 2006

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


Author: Elyse, PMP, CPHIMS
December 15, 2006

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.


Author: Elyse, PMP, CPHIMS
December 14, 2006

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.


Author: Elyse, PMP, CPHIMS
December 14, 2006

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.


Author: Elyse, PMP, CPHIMS
December 12, 2006

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.


Author: Elyse, PMP, CPHIMS
December 11, 2006

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.


Author: Elyse, PMP, CPHIMS
December 10, 2006

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.


Author: Elyse, PMP, CPHIMS
December 9, 2006

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.


Author: Elyse, PMP, CPHIMS
December 8, 2006

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.

Author: Elyse, PMP, CPHIMS
December 8, 2006

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 SV indicates the project's schedule performance. This value can indicate whether the project work is proceeding as planned. Calculate the SV by subtracting the PV from the EV.
CPI Cost Performance Index CPI = EV / AC For the CPI of individual budgets, divide EV by AC. For a cumulative CPI, divide the sum of all EV budgets by the sum of all ACs. A CPI of less than one indicates that the project is over budget, and a CPI of over one indicates that the project is coming in under the estimated budget.
SPI Schedule Performance Index SPI = EV / PV Project managers can use the SPI to help predict when their projects will be completed. To calculate the SPI, divide EV by PV. An SPI of one indicates the project is on schedule; greater than one indicates it is ahead of schedule; and less than one indicates it is behind schedule.
EAC Estimate at Completion

EAC = BAC / CPI

EAC = AC + ETC

EAC = AC + (BAC - EV)

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 = EAC - AC 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 = BAC - EAC 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.
CPIc Cumulative Cost Performance Index CPIc = Σ EV / Σ AC Cumulative CPI Method forecasts the total amount to be spent by adding costs incurred to date to the remaining work to be earned, which has been weighted against the current CPI performance value. Starts from the 20 percent completion point.

Futher Readings:


Author: Elyse, PMP, CPHIMS
December 7, 2006

The project schedule is the PM’s best tool for forecasting how long a project will take to complete. In order to develop the project schedule it is necessary to use several key inputs. The inputs are as follows:

  • Project Scope Statement – The project scope statement is the description of the project scope, major deliverables, project objectives, project assumptions, project constraints, and a statement of work.
  • Risk Register – The Risk Register is used to have a well thought through and accepted evaluation of risk that may delay or halt the project. The PM should consider these events and make adjustments for them.
  • Network diagram – The network diagram is used to obtain the sequencing information of activities.
  • Activity attributes – Activity attributes describe the who, what, where, why, and how of the project activities to be completed. This information is just to group and categorize activities on the schedule.
  • Activity duration estimates – Activity duration estimates determine the length of time (duration) is needed to perform each individual activity.
  • Activity resource requirements - Activity resource requirements detail what type of resource is needed and how many are necessary before the law of diminishing returns hits. This is also necessary for physical resources. For example it is very useful to know what type of platform will be needed and used for testing.
  • Activity list - The Activity List is the listing of all of the work activities that must be performed to complete the project. All activities must be included in the project schedule and have resources available to do the work.
  • Resource calendars - Resource calendars identify the time periods when specific project team members or pieces of equipment are available. Resource calendars show when team members are committed to other projects, are on vacation, or otherwise unavailable to a project.
  • Organizational process assets - The organization's own internal policies may limit the times when work activities can be performed. The organization's policies for employee available hours, overtime, and holidays determine which days—and hours—are work time and non-work time. These are organizational process assets that affect the development of a project schedule.

As with everything the first schedule is a draft which encompasses all the project’s work activities within a defined scope of work. There are two techniques commonly used by project managers to establish a rough timeline:
  • The Critical Path Method - The Critical Path Method (CPM) is a technique for calculating the earliest and latest possible start and finish times for work activities in a project. CPM uses the estimated duration of activities and the dependencies among them to determine limits for when each activity can be performed. CPM also identifies activities in a project that will throw the entire project off schedule if they're not completed on time.
  • Schedule Compression - Schedule compression shortens the overall duration of a project by reducing the duration of individual work activities. Schedule compression methods include:
    • Crashing – Crashing is the process in which more resources are assigned to an activity. The additional cost of resources is offset by the time saved.
    • Fast-tracking – Fast-tracking rearranges the sequence of activities to allow activities that are normally performed in sequence to be done in parallel simultaneously.

Now that we have our first outline of the schedule, the next step is to review the schedule to assure that we have timing for each activity aligned with a the required resource. The techniques commonly used to accomplish this alignment are:
  • Critical chain – The critical chain adds buffers between activities to reduces schedule disruptions caused by missed deadlines or a lack of resources. (These are non work activities)
  • Resource leveling – Resource leveling rearranges the sequence of activities to address limited availability of resources. It adjusts the timing of activities so scarce resources can be allocated to the most critical activities, also levels out over allocated resources.
  • What-if analysis – The What-if analysis compares and measures the effects of different scenarios on a project. By simulating a project's work flow, information can be gleamed on the impacts of adverse events, such as interruptions in the availability of resources, on the schedule.

Another item the PM needs to consider is the Resource Calendar. The resource calendars portrays the availability of resources and constraints within those resources. For example, equipment and people can be assigned to other projects. By reviewing and applying calendars to a schedule restricts the timing of work activities to periods when adequate resources are available.
While engaged in schedule development, it is a good idea to review the relationships between work activities. In most cases the schedule is passed on a finish to start relationship, however perhaps you need to move up the live date by a couple of days on the critical path, or make it a little later not to inflict another live on the organization. These activities can be accomplished by adjusting leads and lags.
  • Leads – Leads are when and activity is scheduled in advance the start date and allowed it to begin before the preceding activity is complete. For example, developing test scenarios can be done a head of time before construction is completed.
  • Lags – Lags are a delay in the starting time of the next activity to create a gap between the end of one activity and the start of the next.

A schedule network analysis is used to examine the project activities, this graphic illustrates the activities, their duration, and sequence. It also gives information on early starts and late starts for the work activities. Just keep in mind the latest late start for the first activity is 1, and all early starts for the first activity are now 0, under the latest PMBOK guidelines. Needless to say, manually creating a schedule network in time consuming, thankfully we have project management software to help the process.

The outputs from the Schedule Development process yield a completed project schedule among other items. The outputs of schedule development are:

  • The Project Schedule – The project schedule includes start and finish dates for project activities, assignments and timing for specific leaders, workers, or other project resources.
  • Schedule Model Data - Schedule Model data is supporting information to the Project Schedule. Schedule Model data includes resource requirements by time period, imposed dates, constraints, and schedule alternatives.
  • The Schedule Baseline – The Schedule Baseline is the bought into, accepted, reviewed, and formalize version of the schedule. When schedule changes are approved, the altered schedule becomes the new Schedule Baseline and the previous baseline becomes obsolete.
  • Requested Changes – Obviously developing the schedule may reveal the need for changes in other parts of the project plan. The analysis of activities during schedule development may show a need to change deadlines, milestones, or resource allocations.

In addition to these outputs, the Schedule Development process updates information created in other project management processes. The following items may be updated as a result of developing a schedule:
  • Resource requirements - The Schedule Development process may produce updates to a project manager's estimate of the resource requirements for a project. Many schedule development techniques adjust the quantity or type of resources, or the timing of when they will be used. For example, crashing a schedule may double the resources on some activities.
  • Activity attributes- As Project managers develop schedules, they may realize that changes are needed in where, when, or how some activities are performed. These changes to activity attributes must be recorded and communicated to the project teams responsible for performing the activities.
  • Project calendar - Project calendars show the days and shifts during which project activities can be performed. When project managers develop the project schedule, they may find it necessary to add days or shifts to the calendar.
  • Project Management Plan - The Schedule Development process produces updates to the Schedule Management Plan, which is part of the Project Management Plan. The completion of the schedule may require new strategies to cope with variances between the schedule and actual activity durations.


Author: Elyse, PMP, CPHIMS
December 6, 2006

The WBS is:

  • A deliverables-oriented collection of project components
  • Serves as the project scope baseline.

The WBS is an input to:
  • Cost Estimating
  • Cost Budgeting
  • Resource Planning
  • Risk Management
  • Activity Definition

The WBS Dictionary explains the WBS components, assigned resources, time and cost for each element.

The WBS 8/80 Rule is that Activiteis from the WBS should not take more than 80 hours or less than eight hours.


Author: Elyse, PMP, CPHIMS
December 5, 2006

How long is something going to take? It is the ever nebulous question. An Estimate is the calculated approximation of a result. An estimate is based upon input data which may not be well defined. When constructing a schedule, it is common to ask resources how long an activity is anticipated to take. This process is called Activity Duration Estimating.
The inputs for Activity Duration Estimating are:

  1. The Activity List – The Activity list identifies work tasks that will be included on the Project Schedule. Remember only activities that are within the scope appear on this list. The Activity List contains all of the tasks for which a duration needs to be projected.
  2. Activity attributes – Activity attributes list the assumptions or constraints about timing and location of activities and who will be responsible for them.
  3. Project Scope Statement – The Project Scope Statement is a broad view of the project helps project managers estimate the duration of project activities. Project managers use the Project Scope Statement as an input because it includes deliverables, constraints, and assumptions that apply to the overall project. Specific milestones or limitations imposed by the project's customer, including project deadlines and reporting requirements, are described in the Project Scope Statement.
  4. Risk Register – The Risk Register describes the effect and probability of events that may delay or disrupt the project. The likelihood of negative events need to be include in the estimate.
  5. Activity cost estimates – Activity cost estimates provide approximate quantities of resources allocated to specific activities. If the budgeted cost for an activity limits how many people or how much equipment can be used for a specific activity, this needs to be accounted for in the duration estimate. Also keep in mind the law of diminishing returns. There is a point in time where resource additions, just won’t help to speed up the project.
  6. Activity resource requirements – Activity resource requirement detail the number of hours of effort or equipment time needed to complete an activity. The type and quantity of resources needed are part of the calculation of activity duration.
  7. The resource calendar – A resource calendar provides availability for people, equipment, and materials needed to do the work activities.
  8. Enterprise environmental factors – Enterprise environmental factors capture the external environment in which a project organization operates. Information about the effect of environmental factors may be gathered from commercially available estimating databases or from the organization's own records.
  9. Organizational process assets – Organizational Process Assets should have historical information about previous project and standard operating time to complete a request.

As more information is gathered about the activities included in a project, the duration estimates can be refined. There are common tools and techniques to estimate how long an activity will take. These are:
  1. Expert judgment - Experienced coworkers or outside advisers can provide expert judgment. They can recommend shortcuts and identify risks that might be overlooked otherwise.
  2. Analogous estimating - Companies perform the same activities in one project after another. Analogous estimating bases estimates on the actual duration of earlier activities.
  3. Parametric estimating - Project managers estimate the duration of an activity by calculating how long it will take to complete a required quantity of work at a standard rate for one employee or one piece of equipment. For example, if we know that it takes 4 hours to setup a single server. We could expect it will take 2 days to setup 4 servers.
  4. A three-point estimate - A three-point estimate adjusts a duration estimate to reflect the probability of both positive and negative events. It's a weighted average of an optimistic or best-case duration, the most likely duration, and a pessimistic or worst-case duration. It is common to use a most likely weight of 4.
    To calculate a three-point estimate of the duration of an activity, do the following:
    • Determine the duration - Determine the duration for the most likely, optimistic, and pessimistic scenarios.
    • Assign weights that reflect the probability each estimate will turn out to be accurate - A weight of 4 is commonly assigned to the most likely estimate likewise the pessimistic and optimistic estimate receive a weight of 1.
    • Multiply each of the estimates by their respective weights - The result is the weighted duration (WD) for that estimate. Total all the weighted durations, and find the sum of the weights.
    • Divide the sum of the weighted durations by the sum of the weights - The result is a three-point duration estimate that reflects risks and opportunities that can affect the activity.
  5. Reserve analysis - Reserve analysis creates a buffer in the schedule. Reserve time is added to the estimated duration of an activity in which delays are very likely. Project managers frequently add reserve time by increasing their initial duration estimates by a fixed percentage. For example, it may be well know that any purchase will take 6 weeks to go through the authorization process.

The process of estimating the duration of project activities creates two resulting outputs which are used as the foundation in developing the Project Schedule.
  1. Activity duration estimates - The first of the outputs is activity duration estimates. The estimated durations show how much time is required for each activity that will appear on the Project Schedule.
  2. Activity attributes – Activity attributes are updated with the assumptions and constraints that are a part of the estimate.

The Activity Duration Estimating process yields an estimate of how long each activity in a project will take to complete.


Author: Elyse, PMP, CPHIMS
December 4, 2006

So you have a project, now it is time to get the team together. First step is to figure out what type of resources will be needed, then how they will be used and even if they are available. Thankfully all of the hard work we have been putting into planning is about to pay off.

Activity Resource Estimating has six inputs. Those inputs are:

  1. Activity List - The Activity List identifies the schedule activities for which resources need to be estimated.
  2. Activity attributes - Activity attributes provide detailed information about the resources required to carry out each schedule activity. They are created during the Activity Definition process and might include information such as responsible persons, constraints, assumptions, and physical locations.
  3. Organizational process assets - Organizational process assets are a company's policies, procedures, and guidelines that dictate how resources must be acquired and used. Many companies also have historical information about similar projects, which can be used to inform the process of Activity Resource Estimating.
  4. Enterprise environmental factors - Enterprise environmental factors can be external or internal to the organization. For Activity Resource Estimating, these factors include considerations about the availability of resources and the company infrastructure, which can affect the success of the project. For example scheduling a project for this year will not do any good, since it is impossible to get a contract through given the timing of the year.
  5. Project Management Plan - The Project Management Plan’s subsidiary pan, the Schedule Management Plan, which describes each schedule activity, when it will occur, and how long it will last.
  6. Resource availability - Resource availability provides project managers with information about the locations and constraints on the use of resources, such as people, materials, and equipment. This information is necessary to ensure accuracy when estimating activity resources. For example, you can schedule a resource for 40 hours of effort a week, but more than likely shooting for 32 hours a week is high, based on other responsibilities.

Since the resources fulfill the activities that run the schedule and the project timeline, it is best not to guess. There are tools and techniques which can be used to determine what resources will do what activities. These tools and techniques are:
  • Expert judgment – Expert judgment involves asking a specialist or someone who has been through this exercise before to assist in Activity Resource Estimating.
  • Alternatives analysis – Alternatives analysis yields options if there are other ways to accomplish the activity. For example, if you are manually sending billing files, instead of extending the effort to automate one could ask operations to do the work.
  • Published estimating data – Published estimating data can be used to determine production rates and the unit costs of resources. Some companies provide extensive information about labor, equipment, and materials requirements for different trades or for working in specific geographical locations. Ask your vendor partner for this data, it is good to have an idea of what is occurring on average.
  • Project management software – Project management software can be used to help you plan, organize, and manage resources. Some sophisticated software programs have additional features that enable you to produce resource calendars and to define resource availability and costs. Check out Primavera, learning curve is high, but that is mainly because the organization is being forced to plan.
  • Bottom-up estimating – Bottom-up estimate is a technique that estimates the resources needed to carry out complex activities. The technique entails breaking the activity down to its component pieces of work, estimating the resources needed for each of the pieces, and aggregating the estimates to find a total.

The best result you can get from estimating what resources you'll need for an activity is when you use all the resources, in full, at the end of the activity. Shortfalls indicate that you had not planned as well as you could have. (Be careful of borrowing from peter to save paul)
The outputs of Activity Resource Estimating enable you to work with just enough resources to meet project objectives. The outputs of activity resource estimating are:
  • Activity resource requirements – Activity resource requirements provide an estimate of the type and quantity of resources needed to complete activities. The Schedule Development process considers when the required resources will be used.
  • Activity attributes updates – Activity attributes are updated because the Activity Resource Estimating process will provide additional information about the nature and amount of resources required to complete each schedule activity. If, as a result of Activity Resource Estimating, approved change requests are generated, then the Activity List and activity attributes are updated to reflect these changes.
  • Requested changes - During the Activity Resource Estimating process, scheduled activities are often created, updated, or deleted from the Activity List. These requested changes must be processed through the Integrated Change Control process.
  • Resource Breakdown Structure (RBS) - The Resource Breakdown Structure (RBS) displays the hierarchical structure of the categories and types of resources needed.
  • Resource calendar - The resource calendar is a composite showing the availability of resources. It describes specific holidays, working hours, and nonworking times.

It's critical that you create these outputs correctly because the information they contain will affect subsequent project management processes. Activity Resource Estimating will help you achieve this and create accurate and realistic schedules as all of the resulting outputs are immediately feed into the Estimating Activity Duration Process.


Author: Elyse, PMP, CPHIMS
December 3, 2006

Sitting in one of too many meetings, the topic was becoming more abstract at a time when things should have been firming up and realization had occurred. So I asked Can you take a minute and explain the dependencies and relationships between the task? Only to get the response of silence, at least we all knew that was the next step.
The relationships between activities and the precedence relationship are all a part of activity sequencing. By declaring precedence and sequencing activities, it is possible to develop an accurate and realistic schedule.
The inputs to Activity Sequencing are:

  1. The Project Scope Statement – The Project Scope Statement reference the product characteristics which could impact sequencing.
  2. Activity List – The Activity List is a listing of the scheduled activities within project scope. Activity sequencing orders this list so they can be scheduled.
  3. Activity attributes – The details about schedule activities that allow scheduling, sorting, and ordering are activity attributes. The attributes may also include activity codes, related activities, physical locations, responsible persons, assumptions, and constraints.
  4. Milestones – Milestones are the important events of the project. The Milestone List assures the activity flow meets project requirements.
  5. Requested changes – Requested Changes are pretty much self explanatory at this point in time.

To create a schedule, a clear idea of what activities must come first or follow others is necessary. Also can some activities be run in series or parallel? Activity Sequencing develops these relationships and yields and understanding of the dependencies among activities. The following tools and techniques can help the activity sequencing process in ways that are easy to interpret:
  • Precedence Diagramming Method (PDM) - PDM is the most widely used network diagramming method. It lets you show four types of activity dependencies: start to start, start to finish, finish to start, and finish to finish. Each activity is represented by a box, or node, and linked by arrows to show which of the four dependencies apply.
  • Arrow Diagramming Method (ADM) - ADM is a network diagramming method in which activities are shown as arrows. ADM can only represent finish-to-start relationships. The sequence in which activities should be performed is shown by joining activity arrows at nodes.
  • Schedule network templates - When projects have similar requirements and components, project managers can streamline the development of network diagrams by using schedule network templates. A template might deal with all or parts of a project's activities.
  • Dependency determination - Determining the types of dependencies is critical to the development of a network diagram. The three types of dependencies used to define the sequence among the activities are mandatory, discretionary, and external.
  • Applying leads and lags - Using leads and lags allows the logical relationships between activities to be accurately described. A lead allows for bringing forward the next activity or letting it overlap the preceding activity by a given amount of time. A lag allows for delaying the next activity by a given amount of time.

Sequencing can be performed by using project management software, manual techniques, or a combination of both. The end result of activity sequencing has project schedule network diagrams that provide visual representations of project activities and milestones, and the order in which they need to be done. It is also very useful to unroll the network diagram so everyone understands exactly where they are in the project later on done the road.
Activity Sequencing process results in outputs which assist in scheduling project activities, allocating resources, and assuring good documentation for the needed project activities. The outputs from Activity Sequencing are:
  • Project schedule network diagrams – The project schedule network diagram is a schematic representation of the relationships between schedule activities. They are the primary output from Activity Sequencing; they help in developing accurate, realistic schedules and in planning the use of resources to meet project goals. A picture is worth 1000 words.
  • Activity List updates – Since the Activity List is a breakdown of the project deliverables into their component activities, approved change requests cause updates to the list.
  • Activity attributes updates - During the Activity Sequencing process, the activity attributes are updated to include the relationships between schedule activities and associated leads and lags.
  • Requested changes - Any requested changes are considered through the Integrated Change Control process.

A quick word of advice: Take the time to accurately sequence your activities, it will save time later and is well worth the effort.


Author: Elyse, PMP, CPHIMS
December 2, 2006

Activity Definition is the process of decomposing a project into a number of tasks which are needed to complete the deliverables. The inputs to the Activity Definition process are:

  1. Enterprise Environmental Factors – Enterprise environmental factors are all of the external and internal organizational influences which may impact the project’s success. Within the process of activity definition it is useful to review all enterprise environmental factors. Afterwards the pm should determine with factors are important to the project and plan accordingly.
  2. Organizational Process Assets – Organizational process assets are the historical information from current or previous projects. The process information can be plans, standard operating policies and procedures, and lessons learned from other projects. These assets are a good qualifying check to determine is the activity appearance of being simple or complex is actually the case.
  3. The Project Scope Statement – The project scope statement provides a description of the project scope, major deliverables, objectives, assumptions, constraints, and the statement of work.
  4. Work Breakdown Structure –The work breakdown structure is the hierarchical decomposition of the work to be completed to deliver the project. The WBS comprises the scope of the project at a work package level. This document can be in outline and/or graphical format.
  5. The WBS Dictionary – The WBS dictionary provides additional information about each component in the WBS. Normally this encompasses a statement of work, the deliverable, associated activities, responsible party, resources needed, cost estimate, quality requirements, and technical reference materials needed among other items. It is useful to identify what other activities may need to be defined.
  6. The Project Management Plan – Two components of the project management plan are used as inputs to Activity Definition. They are:
    • The Project Scope Management Plan – The Project scope management plan describes how the project scope will be defined, developed, verified, and controlled. This is a useful checkpoint to assure only activities which are within scope are defined.
    • Schedule Management Plan – The Schedule Management provides how the schedule will be tracked, how changes to the schedule will be managed and how the work will be monitored.
With these inputs, the project manager can use the information provided to clearly define what activities are to be done to complete the project objectives. As we all know re-invention of the wheel is costly in time and effort, there are tools and techniques which can be utilized to assist in the Activity Definition process.

The tools and techniques are:

  1. Decomposition – Decomposition is the process dividing each work package into smaller manageable parts. Employing the decomposition technique involves reviewing the work packages and deliverables, then defining the activities required to complete the work package and/or deliverable. The Activity List is then created by this process.
  2. Templates – Templates are an organization’s standard documents on how to do things that are similar. So, need an activity list, look at a similar project as a template.
  3. Rolling wave planning – Rolling wave planning is an iterative planning approach commonly used with the larger projects. The project begins with a plan at a high level, as time progress the activities necessary to complete the project become more tangible. The planning process is revisited to refine the high level planning to a detail level. A key point is that the planning wave is always moved to stay ahead of the execution wave.
  4. Expert Judgment – Expert Judgment is the art of listening to those with experience so one can benefit from that expert. Relevant expertise in similar project can be worth its weight in platinum. For example, when implementing a CPOE, isn’t it better to have people on the team who have been there and done that?
  5. Planning component – A planning component is employed when it is difficult to create detailed work packages, because there isn’t sufficient information. A planning component estimates the time and resources necessary to produce the identified work package.
    A planning component comprises two aspects:
    • The control account - A control account is a level within the WBS that can be used to monitor cost and schedule performance. It represents work within a single WBS element, and it is the responsibility of a single organizational unit.
    • The planning package - A planning package describes the work to be done within a control account that has not yet been defined as work packages and schedule activities.

Using the tools and techniques, the project manager will be able to transition the inputs to outputs for the Activity Definition process.

The four outputs of the Activity Definition process are:

  1. Activity List – The Activity List is a list of all the activities that will be performed in the project.
  2. Activity attributes – Activity attributes are details about schedule activities that allow scheduling, sorting, and ordering. Activity attributes have been known to include activity codes, related activities, physical location, responsible persons, assumptions, and constraints.
  3. Requested changes – Request Changes are modifications to the project. When defining activities, requested changes typically pertain to schedule activities and attributes. Requested changes must go through the Integrated Change Control process.
  4. Milestones - Milestones are important events that are either reached within the project—such as the completion of a particular phase—or imposed on the project—such as an ordering deadline. The Milestone List is a component of the Project Management Plan.

Simply stated Activity Definition helps you plan ahead and get results.


Author: Elyse, PMP, CPHIMS
December 1, 2006

Time is a valuable resource. It is also the scarcest. Once time passes, it is never again to be recouped. A project manager must be skillful in managing her time and the time of the team.

The easiest way to manage time effective is scheduling activities. A schedule activity is a discrete scheduled component of work performed during the course of a project according to the PMBOK. In order to have a schedule activity, one needs to have an estimated duration, cost, and resource requirements.

The six Project time Management processes are:

  1. Activity Definition – Activity Definition is a part of the planning process group. It identifies the specific schedule activities which are performed to produce the deliverables.
  2. Activity Sequencing – Activity Sequencing is also a part of the planning process group. It details interdependencies and dependencies among the schedule activities.
  3. Activity Resource Estimating – Activity Resource Estimating is another process that is a part of the planning process group. Activity Resource Estimating basically does what is name defines it calculates the type and amount of resources required for each scheduled activity.
  4. Activity Duration Estimating – Activity Duration Estimating is also a part of the planning process group. Activity Duration Estimating calculates the duration of time that will be needed to complete a scheduled activity.
  5. Schedule Development – Schedule Development involves reviewing the activity sequences, duration, and resource requirements to create the Project Schedule. It is a key component of the planning process group.
  6. Schedule Control – Schedule control manages changes to the project schedule and is a part of the monitoring and controlling process groups.

It is the project manager’s responsibility to continually update the Project schedule to have it reflect accurate project activity. Remember an unachievable schedule is the project manager’s fault.

The five Project Time Management processes take place in the Planning Process Group. It is essential that they are carried out accurately in order to obtain realistic costs, resources, and schedules.


Author: Elyse, PMP, CPHIMS
December 1, 2006

The scope control process has two key parts. First, it controls changes to a project’s scope. Secondly it assure that all scope changes are process by the described Integrated Change Control Process. A scope change is any alteration affecting the agreed-upon project scope detailed within the Work Breakdown Structure. Scope Control is a part of the Monitoring and Controlling Process Group.
Project Manager need to evaluate the effect a proposed change can have on a project. Before beginning to analyze the proposed change, the following inputs are needed:

  • Project Scope Statement – The Project Scope Statement is the document capturing the project scope including the major deliverables.
  • Work Breakdown Structure – The WBS details the scope of the project and the project scope baseline. The WBS is used to determine which work packages could be affected by the change.
  • WBS dictionary – The WBS Dictionary defines the statement of work, milestones, and a unique identifier for each component. The WBS dictionary also helps to define the project's scope baseline and is analyzed to determine how a proposed change affects deliverables.
  • Project Scope Management Plan – The Project Scope Management Plan describes how the scope will be controlled and how changes to the project scope will be managed. The scope stability section indicates the anticipated variation to scope.
  • Performance reports - Performance reports provide information on project status, completed deliverables, and work progress. Unsatisfactory project performance can lead to requests to reduce scope or to perform corrective actions.
  • Approved change requests – Approved change requests are requests used within the Scope Control process to expand or reduce the project scope. Only changes processed according to the agreed procedures are authorized and implemented. These changes often impact cost, time, and quality.
  • Work performance information – Work performance information provides information on the status of changes to the project scope including the status of deliverables and implementation status for change requests, corrective actions, preventive actions, and defect repairs.

Since the need for change is going to occur, there are some tools and techniques that can be utilized to control scope changes. The tools and techniques used in the Scope Control process are:
  • Configuration management system - The configuration management system is a subsystem of the project management information system. It is a collection of documented procedures used to identify and document any changes to the characteristics of a product, and to record and report each change and its implementation status. This system also includes a method for validating approved changes.
  • Change control system - The change control system is critical because it contains formal procedures that outline how project deliverables and documentation should be managed and changed. The system contains the formal process for submitting, reviewing, tracking, and authorizing proposed changes. The change control system is integrated with the systems in place that control project scope. Often, a change control system is the subset of a configuration management system.
  • Variance analysis - To control your project, you need measurements that help you identify whether your project is on the right track. Variance analysis uses information from the project performance reports to assess any possible variations. This technique involves identifying variance—specifically, the difference between what is expected and what is created, and why those differences occurred. Project managers then use this information to decide whether any corrective actions are required.
  • Re-planning – Re-planning must be performed when the proposed scope changes are significant enough to affect existing project documents. A change is considered significant if documents left unrevised become useless as the project progresses. If re-planning occurs, affected documents should be modified. This activity usually includes altering the Work Breakdown Structure (WBS) and the WBS dictionary or the Project Scope Statement.

The quickest way to loose control of a project is the occurrence of arbitrary changes. By controlling changes, project managers can get everyone working towards the same goal – delivering the project on time and within budget.

After reviewing the change, the scope control process has resulting outputs. The outputs are:

  • Updates to the Project Scope Statement - Once changes have been approved, the Project Scope Statement needs to be updated. The Project Scope Statement is used to assess any future changes in scope.
  • Updates to the Work Breakdown Structure (WBS) and WBS dictionary - The Work Breakdown Structure and WBS dictionary need to be in alignment with all other planning documents, reflecting any approved changes in scope. This is because they are used to verify the work results as part of the project.
  • Updates to the scope baseline - The scope baseline needs to be updated because it is used in all aspects of project management, including cost estimates and scheduling.
  • Requested changes - Part of the Scope Control process involves dealing with changes. The Integrated Change Control process specifies how these should be handled. After changes have been processed, the approved changes will need to be implemented.
  • Recommended corrective actions - Some changes occur because of project performance issues. When these types of problems have been identified, corrective actions must be taken to ensure that project work aligns with the project plan.
  • Organizational process assets updates - To learn from variances that occur and how they are handled, the project manager should document the reasons behind the variances and corrective actions, and then update the database so that similar problems can be avoided in future projects.
  • Project Management Plan updates - When changes affect baseline documents, the Project Management Plan needs to be revised. Changes to the Project Management Plan and related documents should follow the Integrated Change Control process. The affected documents can include cost baselines and schedules.


Author: Elyse, PMP, CPHIMS
December 1, 2006

First off, it is always a good practice to verify. Verifying project scope is just an outcome of this fundamental truth. Verifying project scope is the process of reviewing deliverables and work results compared to the Work Breakdown Structure dictionary, the project scope statement, and the project scope management plan. Normally this is completed via inspection and ends with having a formal acceptance of project scope. This activity is typically cyclic occurring at the end of each project phase or as a part of milestone reviews after the quality control check.

There are four inputs used to verify the completed project scope:

  1. Project Scope Management Plan - The Project Scope Management Plan provides information on how the scope will be verified, and it gives guidance on how project scope will be managed. This information supports why the deliverables were created the way they were.
  2. Deliverables - Deliverables are a required input because they are compared against the Project Scope Statement to ensure that they are complete and correct. Deliverables are those items that have been finished.
  3. Project Scope Statement - The Project Scope Statement provides a description of the project scope, including major deliverables.
  4. WBS dictionary - The WBS dictionary provides a brief definition of the deliverables for each component. Information from the WBS dictionary helps project managers verify that the work results are part of the defined project.

A key component of this process is having the stakeholders participate collaboratively and formally accept project scope to assure that the stakeholders are in agreement with the proposed deliverables. There are tools and techniques that can be used for verifying the Project Scope:
  • Measure, examine, and test – Measuring, examining, and testing has the stakeholder review the deliverable to assure that the item was completed satisfactorily.
  • Review current deliverables and work results – The review involves auditing the current deliverables and work results again the Project Scope explained within the Project Scope Management Plan and the Project Scope Statement.
  • Signed documentation of acceptance – The exercise of signing the acceptance form validates the formal nature of the scope verification process. In the signing of the document, there may be caveats and conditions that are added which need to be put into play as corrective actions. If there is no acceptance signature, then the project may need to be cancelled.

An item to remember, but doesn’t really help with anything, if the scope is fulfilled theoretically the project is complete, even if the customer is not happy. However, you should try to make the customer happy if their business has any value to you or if their influence can be damaging.
The process of verifying the project scope results in three outputs. The outputs are:
  • Accepted deliverables - Accepted deliverables refer to formal documents that indicate stakeholder approval of the reviewed deliverables. Typically, a formal document specifies that the primary stakeholder has approved and accepted the deliverable, and it notes any required changes. The documentation may also detail what deliverables were not accepted and the reasoning for not accepting the deliverable.
  • Requested changes - Requested changes can occur as a result of the Scope Verification process. Changes may occur because deliverables are being rejected, or a deliverable may be accepted on the condition that slight changes will be done.
  • Recommended corrective actions - Recommended corrective actions are the actions that must be taken by the project manager or project team members to ensure that any future work on the project aligns with the Project Management Plan.

The purpose of verifying the project scope is to assures that the project team and stakeholders are on the same page


Author: Elyse, PMP, CPHIMS
November 29, 2006

The creation of a work breakdown structure (WBS) is the process of subdividing the major project deliverables and project work into smaller, more manageable components at least according to the PMBOK. There are two formats of presenting a WBS, the outline (MS project view) and Graphical, network diagram view. The WBS ultimately enlightens the team and stakeholders by providing a clear picture of what is needed to complete the project.

The inputs to creating a WBS are:

  1. The Project Scope Statement - The Project Scope Statement is a description of the project scope (including major deliverables, project objectives, project assumptions, project constraints, and a statement of work) that provides a guidelines for making future project decisions and for creating a common understanding of the project scope among the stakeholders.
  2. The Project Scope Management Plan - The Project Scope Management Plan details the actions necessary in preparing the Work Breakdown Structure. This plan also describes how the project scope should be defined, verified, and controlled. This includes a description of the process that should be used to create the WBS from the Project Scope Statement. When reviewing the Project Scope Statement, the project manager should extract the following components to help create the WBS.
    • Objectives - Objectives are what the goal of the project is.
    • Boundaries - Boundaries help determine what is to be included and what is not to be included.
    • Description - The product scope descriptions definitely offers insights to the details involved in decomposing tasks.
    • Deliverables - All deliverables should be contained within the work breakdown structure.

    After reviewing the Project Scope Statement, the project manager should review the Project Scope Management Plan to utilize the following information in creating the work breakdown structure.
    • Decomposition - Decomposition involves breaking a large item down into smaller components.
    • Template - Honestly having standard templates for developing all WBS should be a cornerstone of your organizations project management methodology. The standard template specified in the Project Scope Management Plan should be utilized.
  3. Organizational process assets - Organizational process assets give the project manager a wealth of information regarding standards, procedures, guidelines, and lessons learned from previous projects.
  4. Approved change requests - Approved change requests are authorized changes to the project scope.

Once you have gathered all these inputs together it is time to use some tools and techniques to create the work breakdown structure. The goal of creating the work breakdown structure is only attack a part of the elephant at a time. The tools and techniques used to create a WBS are:
  • Work breakdown structure templates - Work breakdown structure templates from previous project work can be useful. Its easier not re-inventing the wheel every time.
  • Decomposition - Decomposition is used to break a project down into smaller, more manageable components. There are three steps involved in performing decomposition:
    1. Identify the project deliverables - This step involves reviewing the inputs detailed above.
    2. Break the project down into components - This step involves producing a hierarchical descriptions of the project's project. It can be in a graphical or outlined display.
    3. Verify the WBS - In other words check your steps and work. Common quality assurance questions are:
      • Did I include all relevant deliverables?
      • Did I accidentally include any deliverables that are outside the scope of the project?
      • Did I break the project down into the correct components--such as subprojects, sub-subprojects, activities, and deliverables?
      • Did I state all known tasks associated with the creation of each deliverable?
      • Has the WBS been verified by the person or persons indicated in the project documents?

Now that you have done the heavy lifting, it is easy to grasp how important and key the WBS to overall project delivery. Creating the Work Breakdown Structures has six main outputs.
  1. The WBS itself - A WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages.
  2. WBS dictionary - The WBS dictionary is a document that describes each component in the Work Breakdown Structure (WBS). For each WBS component, the WBS dictionary includes a statement of work, defined deliverables, a list of associated activities, and a list of milestones. Other information may include the responsible organization, start and end dates, the resources required, an estimate of cost, the charge number, contract information, quality requirements, and technical references that facilitate performance of the work.
  3. Project Scope Management Plan updates - The Project Scope Management Plan specifies how the scope will be defined and controlled, and how the WBS will be created and defined.
  4. Scope baseline - The scope baseline is a collection of approved documents. These documents consist of the detailed Project Scope Statement, the WBS, and the WBS dictionary.
  5. Project Scope Statement - The Project Scope Statement provides descriptions of the required deliverables and associated work. As the WBS is created, certain changes may need to be made to the described deliverables and work. The Project Scope Statement must be updated to reflect these changes.
  6. Requested changes - When project managers are creating the WBS, they will often find that certain changes affecting the scope need to be made. These changes should be thoroughly reviewed and then approved according to the project's Integrated Change Control process.

The WBS is the foundation. Without the foundation really don't have anything to build upon for your project. Obviously it is needed.


Author: Elyse, PMP, CPHIMS
November 29, 2006

Let’s face it, defining what project scope means is critical. We have all been in the meetings where two or three people leave with different impressions of the discussion. Creating a project scope statement is a key way to ensure everyone is on the same page. The Project Scope Statement defines the project scope and what needs to be accomplished to meet the project’s objectives.
The five inputs to defining project scope are:

  1. Organizational process assets – Organizational process assets provide information about standards that the company has already set in place—standards that are likely to be applied to every project. This information is re-used when creating the Project Scope Statement.
  2. Project Charter – The project charter authorizes the existence of the project. It outlines the project objectives, which project managers need to detail further in the Project Scope Statement.
  3. Preliminary Project Scope Statement – The Preliminary Project Scope Statement provides a description of the major project deliverables, project objectives, project assumptions, project constraints, and a statement of work.
  4. Project Scope Management Plan – The Project Scope Management Plan provides a description of how the stated project objectives will be developed within the detailed Project Scope Statement.
  5. Approved change requests – Change request which are agreed-upon and documented amendments to project scope. Approved change requests will ultimately be added to the Project Scope Statement.

There are several tools and techniques used to developing a detailed Project Scope Statement.
  • Product analysis - Project managers use product analysis to improve their understanding of the project's product. Product analysis is important to scope planning because it helps project managers determine how the product is made.
  • Alternatives identification - When creating a Project Scope Statement, project managers use alternatives identification to produce different ways of approaching project tasks. Lateral thinking and brainstorming are two examples of alternatives identification.
  • Expert judgment - To make informed decisions, project managers use their own expert judgment and the expert judgment of others who have advanced skills or previous experience. These experts help project managers make decisions when developing the Project Scope Statement.
  • Stakeholder analysis - Project managers use stakeholder analysis to identify the potential people, groups, and institutions that may affect or be affected by the project. After identifying the stakeholders, the importance of key people that may significantly influence the project's success is assessed.

After putting the effort in one earns to view the outputs, the outputs of the Scope Definition process are as follows:
  • Detailed Project Scope Statement – The detailed project scope statement is the description of the project scope, major deliverables, project objectives, project assumptions, project constraints, and a statement of work. It provides a documented basis for making future project decisions.
  • Requested changes - A requested change is a formally documented change request that is submitted for approval to the Integrated Change Control process.
  • Project Scope Management Plan updates – Project scope management plan updates are contained within or is a part of the subsidiary plan of the Project Management Plan. It describes how the project scope will be defined, verified, and controlled, and how the Work Breakdown Structure (WBS) will be created and defined.

The detailed Project Scope Statement and the updated Project Scope Management Plan, as well as approved change requests, will be used as inputs for one of the most important items produced as part of the Planning Process Group—the Work Breakdown Structure.


Author: Elyse, PMP, CPHIMS
November 28, 2006

Scope Planning is an important component of the project management. The Project Scope Management Plan is the document that details how the project scope will be defined, developed, and verified while provisioning how scope will be managed and controlled by the project management team. The Project Scope Management Plan also defines how the WBS will be created and detailed.

The following items are the five inputs used to create a Project Scope Management Plan:

  • Enterprise environmental factors – Enterprise environmental factors can influence how the project scope is defined, controlled, verified, and managed.
  • Organizational process assets – Organizational process assets provide information about existing policies, procedures as well as historical records and lessons learned from previous projects. They provide information that is used to help the project manager take measures to control scope in the Project Scope Management Plan.
  • Project Charter – The project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. This objective forms the basis of scope planning.
  • Preliminary Project Scope Statement – The Preliminary Scope Statement begins to define the project and what needs to be accomplished. It includes the product requirements, project boundaries and methods of acceptance. The deliverables are used in scope planning as the basis for the WBS.
  • Project Management Plan – The Project Management Plan is a formal, approved document that provides the structure and outline for the Project Scope Management Plan. It describes which project scope management processes will be performed and at what level they'll be implemented.

In order create the Project Scope Management Plan, project manager often rely on the following tools and techniques.
  1. Expert judgment - Expert judgment is based on expertise in a particular discipline, industry, application area, or knowledge area. Such expertise may be provided by a individual or a group with specialized education, skills, or training, and it is available from such sources as consultants or stakeholders.
  2. Templates, forms, and standards - Templates, forms, and standards are commonly used tools for creating the Project Scope Management Plan. Examples include Project Scope Management Plan templates and project scope change control forms.

An output of Scope Planning is the Project Scope Management plan. This plan is defined as the document that describes how the project scope will be defined, developed, and verified and how the Work Breakdown Structure (WBS) will be created and defined.

The necessary components of the Project Scope Management Plan are:

  • Scope Planning, including information about scope stability – Scope planning contains a description of the preparation of a detailed Project Scope Statement.
  • Scope Definition – Scope Definition contains a description of the preparation of a detailed Project Scope Statement.
  • Work Breakdown Structure – The Work Breakdown Structure contains a description of the creation of the WBS from the detailed Project Scope Statement.
  • Scope Control – Scope Control contains a description of the process for handling changes to the detailed Project Scope Statement.
  • Scope Verification – Scope Verification contains a description of the process for verification or acceptance of the completed project deliverables and the WBS.

To ensure that project tasks are manageable, project managers establish a Project Scope Management Plan.


Author: Elyse, PMP, CPHIMS
November 26, 2006

Managing project scope requires a planning. The project scope is the foundation of all other project management activities and processes. The project scope management processes are:

  • Scope Planning – Scope Planning is all about developing the Project Scope Management Plan. A document that provides how scope will be defined, verified, and controlled. In addition there are elements to discuss how the WBS will be created and defined.
  • Scope Definition – Scope Definition is the preparation of a detailed Project Scope Statement.
  • Create WBS (Work Breakdown Structure) – Creating the Work Breakdown Structure breaks the project deliverables and tasks into smaller and more manageable components.
  • Scope Verification – Scope Verification is the way to provide a quality assurance check by stating how project deliverables will be validated and approved.
  • Scope Control – Scope Control revolves around controlling and managing any changes to the project scope. This is a check and balance to assure the approved scope was implemented.

Now we come to the every popular when and where question. When and where do these processes occur in the five Project Process Groups?
These project scope management processes are interrelated with the five Project Process Groups as follows:
  1. Initiating Process Group - None of the project scope management processes are found in in the Initiating Process Group.
  2. Planning Process Group - Scope Planning, Scope Definition, and Creating the WBS occur in this process group.
  3. Executing Process Group - None are found in this process Group.
  4. Monitoring and Controlling Process Group - Scope Verification and Scope Control are done within this process group.
  5. Closing Process Group - The closing process group does not contain any planning scope processes.

As a pm, it is important to know understand how to fight the evil scope creep. Knowing the project scope management process is a key factor in your fight.


Author: Elyse, PMP, CPHIMS
November 25, 2006

Closing a project follows the same pattern as all other project management processes, there are inputs and outputs associated with closing a project, as well as tools and techniques to help with the process.
The inputs are used to verify project completion and validate that all issues are resolved. The inputs are:

  • Project Management Plan - The Project Management Plan presents how the project is executed, monitored and controlled, and closed. It also documents the collection of outputs from the Planning Process Group processes.
  • Contract documentation – Contract documentation details the requirements of contracts to supply the project with materials or resources, which are deemed to have been successfully delivered or not on the basis of a review of work performance information.
  • Organizational process assets – Organizational process assets are the standards, policies, life cycles, quality documents, and procedures that have a bearing on the completion of the project. They must be updated to take account of any decisions to change or update these policies and procedures during project execution.
  • Enterprise environmental factors – Enterprise environmental factors are any or all external environmental factors and internal organizational environmental factors that surround or influence the project's success.
  • Work performance information – Work performance information is the raw data about the status and quality information of all completed activities. It is used to confirm that all necessary activities have been completed and that the project and its contracts can be closed.
  • Deliverables - A deliverable is any unique and verifiable product, service, or result that must be produced to complete a process, phase, or project. When all deliverables have been approved, the executing processes end and the closing processes begin.

To assure that everything necessary has been completed and the project meets its objectives, a project manager will continue to use the same tools and techniques as from the previous integration knowledge group processes.
The tools and techniques that you'll use in this final phase are:
  • Project management methodology - A project management methodology will provide you with the guidance, procedures, and templates that you'll need to manage project closure. The methodology should provide a guideline to help validate all products have been delivered and approved by the customer.
  • Project management information system (PMIS) – A PMIS is a repository for all project related data, documents, and information. This central repository can be used as an archive for knowledge sharing across future projects.
  • Expert judgment – The team will also need to rely on their collective experience to review the outcomes and determine the project has been satisfactorily concluded.

From project initiation through execution and monitoring, you will have used methodologies, tools, and expert judgment to help you deliver on all aspects of the project. At the close of a project, these tools and techniques will help you ensure that everything is completed, recorded, stored, and accessible for future reference.

Closing a project can vary greatly from one project to another. Every project is different, so each will have different techniques for measuring satisfaction in each area. There are four outputs from closing a project.

  • Administrative closure procedure – The administrative closing procedure includes collecting project records, analyzing project success or failure, gathering lessons learned, and archiving project information for future use.
  • Contract closure procedure – The contract closure procedure addresses the terms and conditions of any agreements relating to the project. The closure procedure ensures that all responsibilities have been met, all results are verified, sign-off is received, and payments are made.
  • Final product, service, or result - The final product, service, or result is the item or items, service, or result that the project was commissioned to deliver. It also includes any ongoing warranty period.
  • Organizational process assets updates - Changes to procedures that impact future projects, completion or termination closure documents, and project files are all process assets that can be recorded in a lessons-learned knowledge base.

Going through the project is very rewarding although time-consuming. It provides an opportunity to learn from the experience, and assurance that everything is truly completed.


Author: Elyse, PMP, CPHIMS
November 24, 2006

In project management, integrated change control is a way to manage the changes incurred during a project. Integrated change control is the described method that manages reviewing the suggestions for changes and utilizing the tools and techniques to evaluate whether the change should be approved or rejected.

The inputs for integrated change control include the following:

  • Project Management Plan – The project management plan is the basis for all project activities, so it offers insights when considering changes and deciding whether to proceed with the change or not.
  • Requested changes – Requested changes arise from the executing or monitoring and controlling process groups.
  • Work performance information – Work performance information acts as an input because the information will influence your decisions on how to handle the requests and recommendations you receive.
  • Recommended preventive actions – Recommended preventive actions are recommendations or requests that are generated as the project progresses. Normally to alleviate, mitigate or avoid a risk.
  • Recommended corrective actions – Recommended corrective actions result from the identification of problems, while others result from the Monitor and Control Project Work process.
  • Recommended defect repairs – Recommended defect repairs are all produced as outputs from the Monitor and Control Project Work process.
  • Deliverables – The project manager may need to make changes to deliverables as a result of decisions made while evaluating change requests.
    Having a functional, working, and understood integrated change control process is a way to manage and handle changes to the project management plan.

To make sure that these changes are reflected in your project components you'll have to use the following tools and techniques:
  • Project management methodology - A project management methodology provides guidelines, procedures, and templates for implementing integrated change control. The methodology may be specific to your organization, external standards, or a combination of both.
  • Project management information system (PMIS) - A PMIS can house project documents and control a user's ability to edit these documents. Additionally, a PMIS can automatically generate notifications to alert team members when documents have changed.
  • Expert judgment - Expert judgment means using your past project experience—and that of your teammates and coworkers—to make decisions about whether to approve or reject requested changes.

Using these tools and techniques it is easier to assure that changes are implemented and recorded and that their impact on the project baseline is recognized.
A control process in place for changes needs to have consideration for the impact the changes will have on the project outcomes. These effects should be updates to the project management plan, scope statement, and deliverables. The outputs of an integrated change control process are:
  • approved change requests
  • rejected change requests
  • Project Management Plan (updates)
  • Project Scope Statement (updates)
  • approved corrective actions
  • approved preventive actions
  • approved defect repairs
  • validated defect repairs
  • approved deliverables.

When evaluating changes needed in a project, speed of evaluation is important. The worst place is to have no anticipated times for a change evaluation decision. Either the project will have time added to its timeline, or changes that are not evaluated will start to consume project resources.


Author: Elyse, PMP, CPHIMS
November 23, 2006

Considering that the Project Management Plan is the baseline for the project. This is guide for monitoring and controlling the project. As a project manager, one will need access to work performance information, performance reports, and change request. This information will need to be at your fingertips as inputs to yield project performance indicators. After analyzing and reviewing the information, it is time to decide whether corrective or preventative actions are needed.

The four inputs to monitoring and controlling project work are:

  1. Project Management Plan – The project management plan is the main source of information about how the project will be executed, monitored, and controlled. It is the plan, with all additional subsidiary plans as needed.
  2. Work performance information – Work performance information is the information about project activities. This includes status information about progress, deliverables, expenses, and quality assurance validations.
  3. Rejected change requests – Reject change request can be enlightening when reviewed in the context of determining how the progress of the project is fairing.

Remember the quality of the measurement is only as good as the data gathered to ascertain the measurement. While it may take time, being vigilant and reviewing this information will save one headaches in the long run.

So how do you sort through the granular details and formulate it into information? Well the good news is this isn’t a single problem, it affects all project managers, and there are standardized tools and techniques for monitoring and controlling project work.

These tools and techniques are:

  • Expert judgment - On the basis of current project information and experience with similar projects, project managers and team members can use expert judgment to make decisions, such as whether to take corrective or preventive actions.
  • Earned value technique (EVT) – Earned Value Technique (EVT) provides project managers with a means of calculating current project schedule and cost performance. Project managers can then use this information to forecast future schedule and cost performance.
  • Project management methodology – The organizational project management methodology provides project managers with detailed guidance and procedures to enable effective monitoring and control through each stage of a project.
  • Project management information system (PMIS) - A PMIS allows for monitoring and controlling parameters such as cost and resource usage. A PMIS can also enable project managers to calculate and manage earned value information, as well as request and update project information automatically.

Using the correct tools and techniques will help keep you in the loop of what’s going on with your project.
Obviously as one monitors and controls there will be some action items that occur. These action items cycle back into the project execution. So what are some outputs or action items that occur during the Monitor and Control Project Work process?

The outputs of monitoring and controlling project work are:

  • Recommended corrective actions - These are based on project work performance information. By comparing this information to the project plan, the project manager or team uses expert judgment to put forward ideas to remedy problems that have arisen.
  • Recommended preventive actions - These are based on project work performance information. By comparing this information to the project plan, the project manager or team uses expert judgment to suggest ways of avoiding project risks.
  • Forecasts - Based on work performance information received during the Monitor and Control Project Work process, forecasts allow the prediction of successful or unsuccessful project outcomes.
  • Recommended defect repairs - These are an output of monitoring and controlling project work. This output recommends the remedial work necessary when a product does not meet quality requirements.
  • Requested changes - These are revised actions that are necessary for meeting project objectives. The requests are often made by the project manager or members of the project team as a way of improving methods or overcoming problems.

Just keep in mind that every organization is different, and your experiences of monitoring and controlling project work will depend on your company's project management methodology and the type of project.


Author: Elyse, PMP, CPHIMS
November 23, 2006

There are times it is about the planning, and then there is always the execution. Ideas are fundamentally wonderful. Implementing them is another matter. Directing and Managing project execution has the same characteristics as most of the PMI processes. There are inputs to the process, tools and techniques to use within the process, and outputs of the process.

Before one starts directing and managing project execution, it is good to have the following approved and validated inputs. Since the inputs are the basis for your course of action, and they are the path followed. It is a good idea to have them validated by the team and stakeholders. The six inputs to directing and managing project execution are:

  • Project Management Plan – The project management plan is the plan on how a project will be executed, monitored, and controlled.
  • Approved corrective actions – Approved corrective actions are authorized and documented actions that are taken to ensure that the project's performance conforms to the project plan. Approved corrective actions help keep projects on track.
  • Approved preventive actions – Approved preventive actions are authorized and documented actions that are taken to reduce the likelihood that risks will damage or adversely affect a project's progress.
  • Approved defect repairs – Approved defect repairs are requested to make fixes that have been authorized and recorded but not implemented. For example, if a defect is found during a quality inspection, a defect repair may be required. This defect repair needs to be approved before any action can be taken. Issues identified during testing that need to be resolved are normally approved defect repairs.
  • Validated defect repairs – Validated defect repairs provide notification that repaired items have either been accepted or rejected following reinspection. After a repair has occurred, the item must be reinspected to determine whether it meets quality requirements.
  • Approved change requests – Approved change requests are project changes that have been agreed on and documented. Examples include changes that affect project scope, the Project Management Plan, procedures, costs, budgets, or schedules. The project team implements changes as part of project execution.
  • Administrative closure procedure - The administrative closure procedure details all the tasks, interactions, roles, and duties required to formalize project completion.

Once you have gathered all the inputs to directing and managing project execution, you should have firm footing to lead you down the path to project nirvana. However along the way there are some tools and techniques, that can aid you in your endeavors.

There are tools and techniques that you can use to direct and manage the execution of your project. They are:

  • Project management methodology - A project management methodology is a documented process that contains roles and responsibilities, procedures, and definitions. A project management methodology can be your organization's own guidelines, or it can be an external standard. The methodology should contain some procedures that provides roles and responsibilities for the project manager, stakeholders, and team members.
  • Project management information system – The project management information system is used to report on project activities, and track the progress on a project.
    To successfully direct and manage project execution, you have to know your team is doing, how they are planning to complete the task, and that everyone is on the same page about project activities. A project management methodology, combined with a project management information system, will helps coordinate activities and assure good communications with the team.

As you are going through the process of executing and directing your project let’s take a moment to discuss the outputs of that process. The outputs are:
  • Deliverables - Deliverables are the outcomes that have been achieved as specified in the Project Management Plan. They might be products, results, services, or a combination.
  • Work performance information - This is data on the status of the project activities being performed to accomplish the project work and is collected as part of the Direct and Manage Project Execution process.
  • Requested changes - A requested change is a change that has been requested by a project stakeholder or team member but has not yet been approved or implemented. Requested changes can be direct or indirect, externally or internally initiated, and either optional, or legally or contractually mandated. These are often identified while project work is being performed. These requests can be to expand or reduce project scope, modify policies or procedures, modify project cost or budget, or revise the project schedule.
  • Implemented change requests, implemented corrective actions, implemented preventive actions, and implemented defect repairs - These all relate directly to the completion of approved work. When creating outputs, you will have to implement the actions that have been approved as inputs.

Remember, for every input, there's an output. Also the old saying is true garbage in, garbage out.


Author: Elyse, PMP, CPHIMS
November 22, 2006

We know that the project management plan is the key document that contains the overall planning, monitoring, and implementing activities to be done in a project. So how does one derive such a document?

First one has to look at what one has around the desktop. The inputs for developing a Project Management Plan are:

  • Preliminary Project Scope Statement - The preliminary Project Scope Statement forms the basis of the scope section of the Project Management Plan and includes a description of the scope, its boundaries, and the major deliverables.
  • Project management processes - Project management processes are descriptions of how the project will be managed. For example, communication management at your company might include status updates included in the project bulletin board.
  • Organizational process assets - Organizational process assets are resources, procedures, or processes, from any or all of the organizations involved in the project, that influence the process or outcome of a project. Plans, policies, procedures, and guidelines may be used to develop the Project Management Plan. For example the process of installing net new equipment in the data center is a part of the processes of the organization. Another is the skill set of current employees.
  • Enterprise environmental factors – Enterprise environmental factors occur within and outside an organization from any or all of the organizations involved in the project that may affect the project outcome. Factors such as a company's culture and market conditions may be used to develop the Project Management Plan.

A key aside is the Project Management Plan needs to consider any conditions or factors that might impact it.

Thankfully, there are tools and techniques that can be used when developing the Project Management Plan. These tools and techniques are:

  • Project management methodology - A project management methodology is an organized approach to creating a Project Management Plan. Methodologies can be simple or complex depending on the project type and the needs of the performing organization.
  • Project management information system (PMIS) - A PMIS is typically a computer-driven system that helps a team develop the project plan. It can calculate schedules, costs, probable outcomes, and expectations. It can also publish the approved document.
  • Expert judgment – Expert judgement is relied upon to develop technical and managerial details to be included in the Project Management Plan. Expert judgment is the technical and management expertise of the project management team. For example an experienced employee and an organization will have more insights into corporate culture, than a new hire.

Now we have the inputs, tools and techniques to use as we create a project management plan. The next step is actually having the plan and its components. The Project Management Plan consists of 11 core components for executing, monitoring, and controlling. There may be more, but the 11 is a good place to start. The eleven core components of a Project Management Plan are:
  1. The processes determined by the project management team
  2. The implementation level of each process chosen by the project management team
  3. The descriptions of the tools and techniques to be used for accomplishing those processes
  4. The chosen project life cycle and related project phases
  5. How the selected processes will be used to manage the specific project
  6. How work will be executed to achieve the project objectives
  7. How changes will be monitored and controlled
  8. How configuration management will be performed
  9. How project management baselines will be maintained
  10. Communication techniques among stakeholders
  11. When management reviews will be scheduled to address issues and pending decisions.

Another way to go about developing a project management plan is gathering and collecting all subsidiary plans in the Project Management Plan. Subsidiary plans are the outputted document for planning from a knowledge area. These can also be included in the Project Management Plan. These plans are:
  1. The Scope Management Plan
  2. The Schedule Management Plan
  3. The Cost Management Plan
  4. The Communication Management Plan
  5. The Process Improvement Plan
  6. The Staffing Management Plan
  7. The Quality Management Plan
  8. The Risk Management Plan
  9. The Procurement Management Plan.

When you create and follow a Project Management Plan that is composed of the nine subsidiary plans, you'll have a map that will guide your decisions and actions and help you reach your desired destination: a successful project.


Author: Elyse, PMP, CPHIMS
November 21, 2006

The preliminary Project Scope statement documents product requirements, project boundaries, methods of acceptance, and high-level scope control. As scope is defined a shared understanding among the stakeholders and project management team occurs, and it is further defined by the projects boundaries. This process of reviewing and analyzing project scope is commonly referred to as the Scope Definition process.

There are four inputs into the process of developing a preliminary project scope. They are:

  1. Project Charter - This is the document that formally authorizes a project.
  2. Statement of Work (SOW) - The SOW is a narrative description of products or services to be supplied by the project. It often indicates a business need, product requirements, and the strategic alignment with the performing organization.
  3. Enterprise environmental factors – The Enterprise environmental factors are conditions within and outside an organization, from any or all of the organizations involved in the project, that may have an effect on the project outcome. Such factors include a company's structure and resources, and market and industry conditions.
  4. Organizational process assets – Organizational Process Assets are resources, procedures, or processes, from any or all of the organizations involved in the project, that influence the process or outcome of a project. Organizational process assets include plans, policies, procedures, and guidelines.

The preliminary Project Scope Statement defines the project and establishes what must be accomplished at a high level. Commonly there are tools and techniques exploited by the project team to create the preliminary Project Scope Statement. These tools and techniques are:
  • A project management methodology - A set of guidelines or principles that can be tailored and applied to a specific situation. This methodology aids a project team in the development of the preliminary Project Scope Statement. For example, the system development life cycle methodology is often used to in IT projects.
  • A project management information system (PMIS) - A PMIS provides tools, including document management and collaboration tools, that can help project managers control project information and aid in the development and publication of the preliminary Project Scope Statement.
  • Expert judgment - The exercising of skills or knowledge gained from previous experience to make decisions on the project at hand. It is applied to technical and management details to be included in the preliminary Project Scope Statement. Am example of expert judgement is the project teams inclusion of patient census and patient days report for the design of a hospital registration reporting system.

Once you have it the preliminary Project Scope Statement content typically includes 14 components – give our take a few as one traverses industries.
  1. Project and product objectives - Project objectives are the measurable success criteria of the project. Product objectives are the desired characteristics of the product, service, or result that the project was undertaken to create.
  2. Product or service requirements and characteristics - These are conditions or capabilities that must be met or possessed by a system, product, service, result, or component to satisfy a contract, a standard, a specification, or other formally imposed documents.
  3. Project boundaries - Project boundaries explicitly define what's included in and excluded from the project.
  4. Project requirements and deliverables - Project requirements describe the conditions or capabilities that must be met or possessed by the project deliverables to satisfy stakeholder expectations. Project deliverables include the outputs of the project and auxiliary results, such as reports and documentation.
  5. Product acceptance criteria - Product acceptance criteria include performance requirements and essential conditions that must be met before project deliverables are accepted.
  6. Project constraints - A constraint is a state, quality, or sense of being restricted to a given course of action or inaction. It is an applicable restriction or limitation, internal or external to the project, that will affect the performance of the project or a process.
  7. Project assumptions - Assumptions are factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration. Assumptions affect all aspects of project planning.
  8. The initial project organization – the project organization consists of the project team members, project stakeholders, and performing organization.
  9. The initial defined risks – Risks are possible events or conditions that would have a significant effect on the project outcome if they were to occur. Some risks, when matched with their possible outcomes, could lead to time and cost overruns.
  10. Schedule milestones – Milestones are key events in the project schedule that may affect the project timeline. Schedule milestones also indicate the completion of a major deliverable. An example is the completion of a design prototype.
  11. Initial work breakdown structure - A WBS is a hierarchical chart that shows the breakdown of a project's activities and deliverables. The initial WBS should consist of a "bare bones" outline of activities and deliverables.
  12. The order-of-magnitude cost estimate – The order-of-magnitude cost estimate is one way to estimate the project's cost. It is an estimate that is made without detailed data.
  13. Project configuration management requirements – Configuration Management requirements describe the degree to which configuration management and change control will be implemented on the project.
  14. Approval requirements – Approval requirements outline approval processes and procedures that can be put in place by any stakeholder. Approval requirements can be applied to project objectives, deliverables, and work.

The Preliminary Project Scope Statement provides a guideline for project decision and assures a shared knowledge of project scope among stakeholders has occurred.

Project managers will continue to refine project scope as the project continues, but they need to develop a preliminary version to establish project scope for progressing through the initial project phases.


Author: Elyse, PMP, CPHIMS
November 20, 2006

Congratulations, you have been elected to write a charter. So with about 5 dollars you head over to your local starbucks and wonder what to do next. A project charter is a pretty systematic document. If you have one at your organization, you can derive several others from that foundational work.

In developing a project charter, there are several inputs to the process:

  1. Contract - The contract that is used as an input is the contract between your organization and the organization you're asking to provide a product or service.
  2. Statement of Work (SOW) - An SOW is a narrative description of products, services, or results to be supplied. The SOW indicates a business need, a product scope description, or a strategic plan.
  3. Enterprise environmental factors – Enterprise environmental factors are any external environmental factors and internal organizational environmental factors that surround or influence the project’s success. These factors include organizational culture and structure, infrastructure, existing resources, industry databases, and market conditions.
  4. Organizational process assets – Organizational process assets are any or all process-related assets, from any or all of the organizations involved in the project, that can be or are used to influence the project's success. These include processes and procedures as well as the organization's lessons learned and other historical information.

The inputs for creating a Project Charter are contracts, Statements of Work, enterprise environmental factors, and organizational process assets. You may not use all of these inputs for every Project Charter, but using some of these inputs is a good place to start before chartering.

A project manager requires an appropriate set of tools and techniques to build a Project Charter. With these tools and techniques, the project manager and project team can act on the inputs to create outputs. Creating a good charter often requires relaying on appropriate tools and techniques:

  • Project selection methods – Project selection methods are used by the performing organization to determine which projects to undertake. Such methods include benefit measurement methods, constrained optimization (mathematical models), and decision models.
  • Project management methodology - The methodology refers to a collection of processes, project process groups, and control functions that include formal and informal methods to help a team develop a charter. One such methodology is called the agile development lifecycle another could be ITIL release management.
  • Project management information systems (PMISs) - A PMIS is a set of automated tools accessible within an organization and integrated into a system. It is used by a team to create a Project Charter, elicit feedback, manage changes, and submit the approved document. Some organizations successfully use project central and sharepoint as their PMIS.
  • Expert judgment – Expert judgement is used to evaluate the inputs needed for Project Charter development. People with specialized knowledge apply expertise to project details during the Project Charter development process.

By applying these tools and techniques to the Project Charter inputs, the project manager and project team can develop the Project Charter.

Developing the Project Charter is the start for the rest of the project. The inputs and tools and techniques are used to create the Project Charter, which is the output of the Develop Project Charter process.

A Project Charter provides an overview of the project and its goals. The Project Charter details the project purpose, overview, goals, and high-level deliverables.

The elements of a Project Charter are:

  • The project overview - A project overview contains a description of the business need, purpose, and product or service that is to be provided.
  • Preliminary roles and responsibilities - This section describes the duties of the project team. This includes people who should be involved and why and how they might be involved. This might include customers, stakeholders, and the project team.
  • Identification of the project manager - The project manager identification designates the project manager who has primary project oversight responsibility.
  • A description of the project manager's authority - The description of the project manager's authority outlines the level of authority given to the project manager. This would include financial oversight and level of decision making.
  • Sign-off - This is the approval required from the project's sponsor to give the go-ahead to the project.

When the sponsor or sponsors sign off on the charter, it marks the beginning of the planning phase of a project.


Author: Elyse, PMP, CPHIMS
November 20, 2006

Project integration management is primarily concerned with integrating processes to accomplish project objectives.
The seven process are:

  1. Develop Project Charter – Develop the Project charter is initiates the project. The derived project charter approves and sanctions the project and gives the project manager the authority to act and apply organizational resources to the project.
  2. Develop Preliminary Project Scope Statement – The preliminary project scope statement is an initial, high-level definition of the project scope. This document defines the project’s product or service, methods of approval, and tactical strategies for the change control process.
  3. Develop the Project Management Plan – Developing the Project Management Plan includes all activities needed to create and integrate all subsidiary plans into the Project Management Plan. This plan will be how the project is executed, managed, and monitored.
  4. Direct and Manage Project Execution - Directing and Managing Project execution is orchestrating how the project team performs the actions to implement the Project Management Plan and complete the work detailed in the Project Scope Statement.
  5. Monitor and Control Project Work – Monitoring and Controlling Project work measures and balance the projects progress and any corrective or preventative actions needed to assure all project objectives are met.
  6. Integrated Change Control – Integrated Change Control is the change control process for the project which includes evaluating all change requests, authorizing changes, and managing changes to project plans and deliverables. The key benefit to this process is that only validated approved changes are implemented.
  7. Close Project – Closing the project equates to completing all project activities, delivering the final project, turning over continual support to operations, and obtaining the client approval to formally close the project.

The seven processes in the Project Integration Management knowledge area work in concert to facilitate proper project coordination. The project integration requires each process seamlessly links and fuels the next process
All project management processes are divided into the following five project process groups:
  • Initiating - The Initiating Process Group includes those processes necessary for formally authorizing the beginning of a new project. The processes for developing the Project Charter and developing the preliminary Project Scope Statement occur in the Initiating Process Group.
  • Planning Process Group - The Planning Process Group includes those processes that establish the project scope, create the Project Management Plan, and identify and schedule the project activities. The process for developing the Project Management Plan occurs in the Planning Process Group.
  • Executing Process Group – The Executing Process Group consists of those processes necessary for completing the work outlined in the Project Management Plan to achieve the project's objectives. The process for directing and managing project execution, which ensures that the Project Management Plan is implemented properly, occurs in the Executing Process Group.
  • Monitoring and Controlling Process Group - The Monitoring and Controlling Process Group is necessary for gathering, assessing, and distributing performance information and analyzing measurements and trends to make continual process improvements. The processes for monitoring and controlling project work and implementing integrated change control occur in the Monitoring and Controlling Process Group.
  • Closing Process Group – The Closing Process group consists of those processes necessary for officially ending project activities and handing off the completed product to others. This also includes closing a project that has been canceled.

The project process groups overlap, interact, and directly affect one another as they all play out the greater project plan. These interactions create project management synchronization.


Author: Elyse, PMP, CPHIMS
November 20, 2006

Project closure is an important part of the overall project lifecycle. It brings things to the ended state in a formal approved way. PMBOK defines the Closing Process Group as “Those processes performed to formally terminate all activities of a project or phase, and transfer the completed product to others or to close a cancelled project.
It’s a nice way to move the project into the normal business operations or review cancelled projects to gleam information from them.

Projects are cancelled for numerous reasons. A late start to a project can ultimately cause the project to cancel. Budget cuts can cause end the funding of a project and bring it to a pre-mature end. Having a project with an inadequate skillset can bring about the end of a project. Also having a plethora of project changes can result in draining the life from the project, causing a cancellation situation. Also the idea of with ultimate resources one can rebuild the pyramids or unrealistic project objectives bring about the cancellation of a project - at least in profit based organizations.

Whether a project is successful or not, it is good to record the lessons learned from the project. These lessons are feed from the successes and failures in the project. It is important to keep this information and inject the knowledge into other project, current and future.

The Closing Process Group coordinates project completion required to close or cancel a project and document the lessons learned. There are two key processes that need to be executed in closing activities:

  • Close Project - Close Project is defined by PMBOK as: "The process of finalizing all activities across all of the Project Process Groups to formally close the project or phase." The Close Project process can be described as documenting administrative procedures for the completion of a project and preparing contract closeouts. For example updating the organization process assets within the configuration management database are typical project closing activities.
  • Contract Closure – Contract Closure is defined by PMBOK as “The process of completing and setline the contract, including resolution of any open items and closing each contract” This is essentially the completion and settling of contracts.

A closed project may mean cause for celebration or a sigh of relief. It definitely means that the project phase has been completed, the project has been finished, or it was cancelled.


Author: Elyse, PMP, CPHIMS
November 20, 2006

Monitoring and Controlling a project touches every facet of the project lifecycle. Changes can occur that impact project scope, time, cost, and quality. These changes need to be managed to assure there are no downstream impacts. While engaged in a project it is necessary to be aware of the impacts and affects of too little or too much resources and communications.

Within the Monitoring and Controlling Process Groups there are ten processes utilized. Five processes address scope, time, cost, and quality including the change herewith in the project lifecycle. The other five processes are overseeing the resources, communications, risk, and procurement processes.

The five process that address changes to scope, time, cost, and quality are as follows:

  • Scope Verification – Scope verification is the process to obtain official acceptance of the completed project scope. A project scope that has not been officially reviewed and signed off on won't be beneficial as the project progresses.
  • Scope Control – Scope Control engages in managing changes to the Project Scope. The Project Scope encompasses any identified work that will produce a product, service, or result.
  • Schedule Control – Schedule Control is the process of managing changes to the Project Schedule. The Project Schedule outlines the timeline for various deliverables.
  • Cost Control – Cost Control is the process of directing the cost factors that create variances, and controlling budget changes. Since the budget identifies agreed-upon expenditures for every line item, it has to be supervised closely.
  • Perform Quality Control – Perform Quality Control involves monitoring the specific results of a project to assess whether those results are consistent with relevant quality standards. It also identifies ways to eliminate causes of unsatisfactory performance.

This Process Group also has the role of monitoring resources, communications, risk, and procurement. These variables must be contained as well to keep a project on track.
  • Manage Project Team - The Manage Project Team process tracks team performance, giving feedback, handling issues, and coordinating changes to improve project performance. The goal is to improve overall performance through assessment, guidance, and problem solving.
  • Performance Reporting – Performance reporting involves collecting and disseminating information about performance. This includes status reporting, progress measurement, and forecasting. This process is about measuring, documenting, and forecasting project performance.
  • Manage Stakeholders – Managing Stakeholders is the process of managing communications with project stakeholders to satisfy their requirements and resolve their issues. This process involves diplomacy, tact, and a willingness to facilitate a two-way conversation.
  • Risk Monitoring and Control – Risk monitoring and control involves assessing identified and residual risks, identifying new risks, executing risk response plans, and assessing the responses plan’s effect on the project.
  • Contract Administration - Contract Administration is the process with deals with contracts and contract changes. Contract Administration manages the relationship between the buyer and the seller, and is the foundation for future vendor/business relationships.

With twelve processes in total, the Monitoring and Controlling Process Group is comprised of processes spreading across all nine Knowledge Areas. Remember iteration and constant vigilance is key when engaged in project management the processes of the monitoring and controlling process group will be a key tool in measuring project performance.


Monitoring and Controlling Project Work and Integrated Change Control processes are how one obtains information about the health of a project. These processes extended throughout the project lifecycle and are fueled by information from each of the other processes in the group.

The Project Integration Management knowledge area relates to the synchronization of all project activities to create a unified whole. Monitoring and Controlling Project Work and Integrated Change Management are a part of Project Integration because:

  • Monitoring project work extends through all five Process Groups to ensure an effective project.
  • Integrated Change Control process also occurs throughout the project and its purpose is to manage changes in a coordinated fashion.

Monitoring and Controlling project work and Integrated Change control utilized the schedule progress, deliverables completion information, quality results and cost expenditures from the work performance information of the Executing Process Group. The Monitoring and Controlling Project work process compares the actual results to the planned results to obtain variances in order to determine the corrective actions needed to re-align project performance. The outputs of monitoring and controlling are recommended corrective actions, recommended preventative actions, forecasts, recommended defect repair and requested changes.

The Integrated Change Process keeps track of the conditions that may create a project change, manages change when these conditions occurs, and evaluates the benefits of change based on the effect to the triple constraints: scope, cost, time, risk, quality, and customer satisfaction. The outputs of the Integrated Change Process are approved and rejected change requests, Project Management Plan and Project Scope Statement updates, approved corrective actions, approved preventative actions, approved defect repair, validated defect repair, and deliverables.


Author: Elyse, PMP, CPHIMS
November 18, 2006

A project needs consisting monitoring and controlling in order to stay within scope, be completed on time and within budget. The Monitoring and Controlling Process Group has twelve processes which help to oversee project execution by measuring actual performance versus planned performance. There is also the constant vigilant outlook for variances or deviations from the Project Management Plan.

The monitoring and controlling process group governs the project management plan with two main actions. First it monitors and measures project performance making adjustments as needed with the end goal of maintaining the project on its pre-planned course. Secondly, it provides the checks and balances needed to determine how a project is performing. Obviously the monitoring and controlling process groups are iterative with a tendency to often repeat to check project status.

The PMBOK states: “The key benefit of this process group is that project performance is observed and measured regularly to identify variances from the Project Management Plan” when referring to the monitoring and controlling process group.


Author: Elyse, PMP, CPHIMS
November 18, 2006

The Executing Process Group’s function is to coordinate people and resources to complete project work as outlined in the Project Management Plan and to meet project objectives. According to the PMBOK, the executing process groups is those processes performed to complete the work defined in the Project Management Plan to accomplish the project’s objectives in the Project Scope Statement.

The Executing Process Group is fueled by the output of the Planning Process Group. The Executing Process Group contributes directly into the monitoring and controlling process group.

To complete the work defined in the Project Management Plan and meet project objectives outlined in the Project Scope Statement, the project manager must find ways to get people organized and maximize the resources available.

The Executing Process Group processes rely on five different Knowledge Areas: Project Integration Management, Project Quality Management, Project Human Resource Management, Project Communication Management, and Project Procurement Management.

The seven processes that make up the Executing Process Group are:

  1. Direct and Manage Project Execution – the Direct and Manage Project Execution is the directing of the technical and organizational aspects of project activities. It is the overarching executing project and where a majority of project work is carried out. The Direct and Manage Project Execution process inputs are the document work plans from the planning process group, and the approved corrective/preventive actions, change requests, and defect repairs that are generated during project execution. The output for Direct and Manage Project Execution are the deliverables, work performance information, all changes, corrective actions – including defect repair, and preventative actions take to improve project work performance.
  2. Perform Quality Assurance - The Perform Quality Assurance process is about ensuring that project processes and activities meet expectations through quality activities. Without quality control, a project may not be executed according to requirements. The process of Perform Quality Assurance is a part of the Project Quality Management knowledge area.
  3. Acquire Project Team - The Acquire Project Team process is extracted from the Project Human Resource Management knowledge area. Project team members are a critical part of managing project tasks and directing activities. Without a project team, the project is overwhelming. The Acquire Project Team process yields project staff assignments, resource availability, and updates to the Staffing Management Plan as outputs.
  4. Develop Project Team - Develop Project Team is from the Project Human Resource Management knowledge area. The output is the team performance assessment. Obviously encouraging and developing teamwork is a necessary component of any project.
  5. Request Seller Responses - Request Seller Responses is the process of obtaining information, quotations, bids, offers, or proposals. A key component of this process is to obtain a listing of qualified vendors to do the project wok and provide necessary materials. The outputs of Request Seller Responses are the request for information, RFI, and request for proposal, RFP.
  6. Select Sellers - The Select Sellers process involves choosing appropriate sellers and negotiating viable contracts, typically sellers maybe chosen based on a list of weighted requirements with a little bit of the analytical hierarchy process. Selecting Sellers process relies on the Request Seller Responses process, which obtains necessary information so that appropriate sellers can be chosen. The Select Sellers process identifies a pool of potential vendors and contracts. It creates a Contract Management Plan, resource availability, updates to the Procurement Management Plan, and requested changes.
  7. Information Distribution - The final process of the Executing Process Group is Information Distribution. This process involves disseminating appropriate information to team members and other stakeholders as detailed in the Communications Management Plan. The Information Distribution process outputs are organizational process assets (updates) and requested changes. Project Communications Management involves effectively linking people with the information they need.


Author: Elyse, PMP, CPHIMS
November 17, 2006

Procurement Management Planning is the process of examining project components to determine what and when to purchase or buy. This includes the method of documenting the requirements and identifying the potential sellers of the needed component.

First, you have to plan purchases and acquisitions, this is where you determine what to purchase when and how to obtain it. This process needs to be considerate of constraints, assumptions, boundaries and requirements.

The Plan Purchases and Acquisitions process lays the groundwork for the Plan Contracting Process. The outputs of this process are as follows:

  • Procurement Management Plan - This document describes how procurement processes from developing procurement documentation through contract closure will be managed.
  • Contract SOW - These documents describe the procurement item in enough detail to allow prospective sellers to determine if they can provide the item. The SOW can be refined as the procurement process progresses until it is part of a signed contract.
  • Make-or Buy Decisions documents - These documents list what project material, products, or services will be acquired or developed in house. They also include a short justification for each decision.
  • Requested Changes - These arise during this process may result in updates to the Project Management Plan and its subsidiary plans. These updates typically take the form of additions, modifications, or revisions from the previous plans.

The Plan Contracting process has three outputs which are either dependent or mutually exclusive. The three outputs are as follows:

  • Procurement Documents – The procurement documents are used in bid and proposal activities such as an Invitation for Bid and a Request for Quotation. To facilitate an accurate and complete response from each prospective seller, they include the SOW, the type of response required, as well as other specifications.
  • Evaluation Criteria – Evaluation Criteria are established items used to rate or score proposals. These criteria, which are often included as part of the Procurement Management Plan, can be objective or subjective. They can also be limited to a single measure, or include a detailed list of selection criteria.
  • Contract SOW (updates) - The constract statement of work ensures that the information the seller needs to submit an accurate proposal is current. Since potential sellers use this information to determine whether or not they can supply the required item, this updated document is often included within the Procurement Documents.


Author: Elyse, PMP, CPHIMS
November 16, 2006

Risk Management processes aid in determining the potential hazards or opportunities for a project. That’s right, risks are not always negative.

Five of the Risk Management processes are:

  1. Risk Management Planning - Risk Management Planning is about planning to make good wise decisions. This is normally done early in project planning with consideration to project scope and significance to the organization. Documents to review while engaged in risk planning are: Enterprise Environmental Factors, Organizational Process Assets, the Project Scope Statement, and the Project Management Plan. The output of this process is the Risk Management Plan, which details how Project Risk Management will be organized and executed on the project. The Risk Management Plan contains the following components
    • Methodology
    • Roles and Responsibilities
    • Budgeting
    • Timing
    • Risk Categories
    • Definitions of Risk Probability and Impact
    • Probability and Impact Matrix
    • Revised Stakeholders' Tolerances
    • Reporting Formats
    • Tracking

  2. Risk Identification process – Risk Identification is the activity engaged in identifying potential risk that might happen and describing their attributes. Risk Identification process usually leads into the Qualitative Risk Analysis process or the Quantitative Risk Analysis process. Risk Identification is often completed with the knowledge garnered from Enterprise Environmental Factors, Organizational Process Assets, the Project Scope Statement, the Risk Management Plan, and the Project Management Plan. The output of this process is the Risk Register which details all identified risks, including description, category, the cause of the risk, probability of the risk occurring, impact on objectives, proposed response, owners, and current status.

  3. Qualitative Risk Analysis - Qualitative analysis of identified risks requires the output of the Risk Management Planning and Risk Identification processes, including the Risk Management Plan and the Risk Register in addition to the Organizational Process Assets and the Project Scope Statement. This process updates the Risk Register with the priority and categorization of the risks. Based on the results, from the qualitative analysis you should proceed with either the quantitative risk analysis or the risk response planning processes.

  4. Quantitative Risk Analysis - The Quantitative Risk Analysis process involves numerically analyzing the effect on overall project objectives of identified risks. This process relies on considering the organizational process assets, project scope statement, the risk management plan, the risk register, and the project management plan. The end result is to minimize the impact of identified risks, so updates to the risk register for probability of impact, and trend identification will occur as an output of this process.

  5. Risk Response Planning - Risk Response Planning’s goal is to decrease the probability of identified negative risks. This can be accomplished by inserting resources into the budget, schedule or plan. Another aspect of risk response planning is determine how to increase the likelihood of positive risks on the project. The output of this process is an updated risk register including
    • a description of the risk and its causes, the project area it may affect, and its impact on project objectives
    • the identities of the risk owners and their assigned responsibilities
    • results from the Qualitative and Quantitative Risk Analyses
    • a description of the response to each risk, such as avoidance, transference, mitigation, or acceptance
    • the actions necessary to implement the responses
    • the budget and schedule for risk responses
    • the contingency and fallback plans

The key to risk management planning is that by understanding and performing the processes involved with identifying and analyzing your project's potential threats and opportunities, you can minimize or even avoid the impact of those risks to your overall project outcome, while maximizing any potential for gain, reward, or success.


Author: Elyse, PMP, CPHIMS
November 15, 2006

One of the secrets of project management is the precise execution, doing the right things, with the right people at the right time. Communication Management Planning helps to assure this occurs.

Communications Planning ascertains the information and communication needs of the project stakeholders, project team, and leadership. (This should be reviewed with a frequency in case needs are changed.)

The Comunications Management Plan will detail:

  • the communications needs and expectations for the project
  • how and in what format information will be communicated
  • when and where each communication will be made
  • who is responsible for providing each type of communication


Author: Elyse, PMP, CPHIMS
November 15, 2006

Human Resource Planning begins with reviewing the preliminary Activity Resource Requirements. This review determines the people and skill sets needed for the project. While engaged in the review it is a good practice to keep in mind the enterprise environmental factors that can constrain your plan. The outputs of Human Resource Planning are:
  • Roles and Responsibilities document - The Roles and Responsibilities document details the required skillsets, individual roles, responsibilities, and levels of authority needed to complete the project.
  • Project Organization Chart - The Project Organization Chart is picture of the project reporting relationships.
  • Staffing Management Plan - The Staffing Management Plan describes the staffing requirements, competencies, and training needs for the project, when and how people will be added to and taken off the project, compliance and safety concerns, and the impact of such a plan on the organization(s) involved in the project.
Further Reading:

Author: Elyse, PMP, CPHIMS
November 15, 2006

Quality Planning is the process of identifying which quality standards are relevant to the project and ascertaining how to meet those standards. The inputs to the quality processes are:

  • Enterprise Environmental Factors - Any external and internal environmental factors from all of the enterprises involved in the project, that surround or influence the project's success. This includes existing resources, market conditions, infrastructure, and organizational culture.
  • Organizational Process Assets - Any or all process-related assets, from any or all of the organizations involved in the project that can be or are used to influence the project's success. These can include items such as policies, procedures, lessons learned, and historical information.
  • Project Scope Statement - A description of the project scope, major deliverables, objectives, assumptions, constraints, and a statement of work that provides a documented basis for future decision-making and for developing an understanding among the stakeholders.

Based upon these inputs the Quality Planning processes yield the following outputs.

  • Quality Management Plan - The quality management plan addresses the quality components for the procect, including but not limited to quality control, quality assurance, quality improvement and continuous process improvements.
  • Quality Metrics - The quality metrics detail the description of a project component and how the Quality Control processes will handle quality assurance around the component.
  • Quality Checklists - Quality Checklists are used to monitory a part of the project to assure and validate that a specific set of steps or procedures has been performed.
  • Process Improvement Plan – Process Improvement Plans detail how to review and analyze process by streamlining or simplifying to improve customer value.
  • Quality Baseline – The quality baseline measures the miniminum quality requirements for the project.
  • Project Management Plan (updates) -The updated Project Management Plan will incorporate all additions, modifications, or revisions resulting from the Quality Planning process.


Author: Elyse, PMP, CPHIMS
November 14, 2006

The goal of a project manager is to complete your project on time and within budget. The best way to accomplish your goal is to plan for it, so the two key task in planning are costing and scheduling. Therefore understanding the Cost Estimating and Cost Budgeting processes that develop the costing documents will help you obtain your goal.

Cost Estimating is the process of developing an approximation of the cost of the resources needed to complete project activities including the consideration of the possible fluctuations and other variances such as risk. Throughout the Cost Estimating process various alternatives are considered to assure accurate and effective estimates. This process is conjoined with the Activity Resource Estimating process and is foundational work necessary for Cost Budgeting. The inputs to the cost estimating process are outputs from the other planning processes. These include the project scope statement, the project management plan, the work breakdown structure, staffing management plan, enterprise environmental factors, and organizational process assets. The main outputs of the cost estimating process are the Activity Cost Estimates and the Activity Cost Estimate Supporting Detail.

  • Activity Cost Estimates -These are assessments of the probable costs of the resources necessary to complete project activities.
  • Activity Cost Estimate Supporting Detail - This provides a description of the activity's scope of work, documentation about how the estimate was developed, known constraints, explanations of any assumptions that were made, and a range of possible results.

Two additional outputs of the Cost Estimating process are Requested Changes and Cost Management Plan (updates), which incorporate desired and approved changes that are believed to have an impact on the project's cost management.

Cost budgeting is the process of aggregating the estimated costs of individual activities or work packages to establish a cost baseline. It requires having all cost estimating processes completed. The difference between cost estimates and a cost budget is that the cost estimates portray costs by category, versus a cost budget which displays costs across time. The inputs into the Cost Budgeting process are:

  • Activity Cost Estimates - These predict the cost for the project work.
  • Activity Cost Supporting Detail - This provides useful data on how the estimate came about.
  • Project Schedule and the Resource Calendar - Both dictate when project activities occur and when associated budget monies will be spent.
  • The Contract This details purchasing requirements and associated cost.
  • The Cost Management Plan -This reflects how project costs will be controlled.

The end result of the Cost Budgeting process is a Cost Baseline, which is a time-phased budget that will be used to measure and monitor overall cost performance on the project—usually displayed in the form of an S-curve. Additionally, the Cost Budgeting process will produce Project Funding Requirements, including a management reserve amount that is included along with the cost baseline to compensate for either early progress or cost overruns.


Author: Elyse, PMP, CPHIMS
November 13, 2006

Good News, we have a Work Breakdown Structure, now all we need is to set a realistic timeline to accomplish the necessary activities. An activity refers to the component of work performed during the course of a project. There are several project time management activity processes that help organize your project to assure a timely completion.

During the activity definition, work packages in the WBS are further detailed into their activities. This helps to provide accurate estimates and improved management control. The output of this process is an Activity List. An activity list is a comprehensive list of all the activities necessary to complete the project.

The companion to the Activity list is the list of Activity Attributes. This normally includes:

  • activity identifiers like codes and descriptions
  • schedule and resource data
  • identified assumptions and constraints
  • the responsible party
  • work location
  • WBS classification
  • activity type

The final output of the Activity Definition process is the Milestone List of significant events in the project.
The sequence of activities is critical to any project. Activity Sequencing is the process of logically organizing the activity list while being cognizant of interactivity dependencies, leads and lags. The outcome of this process is an input to the Schedule Development process.

The Activity Resource Estimating process obtains what resources each project activity will require, starting from the most granular level of the WBS. Often Activity Resource Estimating is completed in accordance with Cost Estimating, because resources involve money.

The Activity Resource Estimating process yields what resources and quantities are required for each project activity, the Activity Resource Requirements. Other outputs are the Resource Breakdown Structure and a resource calendar.

Activity Duration Estimating is the process of estimating the number of work periods that will be needed to complete individual schedule activities. One should create duration estimated based upon the follow information:

  • Enterprise Environmental Factors
  • Organizational Process Assets
  • Activity List
  • Activity Attributes
  • Project Scope Statement
  • Activity Resource Requirements
  • Resource Calendar
  • Project Management Plan with cost estimates and a risk register.

During the schedule development process, schedule-related assumptions and constraints from the Project Scope Statement are evaluated in light of setting start and finish dates for project work. The output of the Schedule development process is an approved project schedule with a baseline.

Additional another output is the Schedule Model Data. This is the supporting details such as alternative schedules, extra time, and identified assumptions and constraints.


Author: Elyse, PMP, CPHIMS
November 13, 2006

Once the initiating process group has been completed, the two main outputs, the project charter and preliminary project scope statement are inputs to the planning process group.

The project charter is a document issued by the sponsor that formally authorizes the existence of the project, and this document gives the project manager the authority to act and apply organizational resources to project activities.

The preliminary Project Scope Statement is a high level review of project scope. It includes major deliverables, scope objectives, constraints and assumptions, and a statement of work. One can use the preliminary project scope statement as a basis for future decision making and a confirmation of stakeholder alignment.

What is the planning process group? The planning process group develops the project management plan, engages in scope planning, details scope definition and creates the work breakdown structure, wbs.

Let’s face it the project management plan is the key document in overall planning, monitoring, and implementing a project. This plan lays out the who, what, when, where, why, and how of the project, at the same time it also communicates this to the stakeholders.

The development of this plan begins right before the scope planning process and is the lead in to determining detailed project scope. Revisions continue throughout the planning process s information continues to come to light..
As one engages in the planning process there are many knowledge areas that are considered. Each of these knowledge areas have a subsidiary plan that needs to be reviewed from the perspective of the project management plan.

The knowledge areas with subsidiary plans are:

  • Scope Management Plan
  • Schedule Management Plan
  • Cost Management Plan
  • Quality Management Plan
  • Process Improvement Plan
  • Staffing Management Plan
  • Communication Management Plan
  • Risk Management Plan
  • Procurement Management Plan

The Project Scope Management plan ascertains how scope will be defined, verified, and controlled. It also defines the process used to develop the detailed scope statement and details how the work breakdown structure will be produced, defined, maintained and validated. The Project Scope Management Plan established the process that will be followed to control how requests for changes to the detailed project scope state will be handled this process is connected to Integrated Change Control.

Scope Definition is the development of a detailed project scope statement. The detailed project scope statement expands upon the major deliverables, assumptions and constraints in the preliminary project scope statement.
However, the detailed project scope statement has some granular project information. So key points to include are:

  • Project Objectives
  • Product Scope Description
  • Project Requirements
  • Project Boundaries
  • Project Deliverables
  • Product Acceptance Criteria
  • Project Constraints and Assumptions
  • Initial Project Organization
  • Initial Defined Risks
  • Schedule and Cost Factors

Finally let’s review the creation of the work breakdown structure. First, analyze the detailed Scope Statement. List the project’s major deliverables and then determine the work required to product those deliverables. Divid the work into activities and decompose those activities into work packages. The work packages represent the portions of work that are small enough to all you to accurately estimate cost and schedule. A final QA check is to verify that the lower-level WBS components are sufficient and needed to complete the corresponding higher-level deliverables.

So to start with you would have at least three levels of the work breakdown structure.

1. Identify a major deliverable for the project.
2. Break down the deliverable into activities.
3. Decompose activities into work packages

The Create WBS process lays the groundwork for every other planning process that follows, including:

  • Activity Definition
  • Activity Resource Estimating
  • Cost Estimating
  • Cost Budgeting
  • Risk Management Planning
  • Human Resource Planning
  • Quality Planning
  • Communications Planning
  • Plan Purchases & Acquisitions

After you have completed the WBS, it is a really good idea to create an accompanying WBS Dictionary. This provides a description of each of the elements, and is helpful for those jargon centered organizations like healthcare where one term can mean seven different things. Another output of the creation of the work breakdown structure is the project’s scope baseline.


Author: Elyse, PMP, CPHIMS
November 10, 2006

It is the interdependencies! In order to understand how to manipulate, the first thing you need to do is understand the interdependencies. The Planning Process group has 21 processes comprised of activities that are a key component of the control and implementation of the project through its lifecycle.

So how do these process interact?

First, they are interdependent and subject to change. Since the planning process group involves constantly gathering information, as new information becomes unveiled, some planning processes will need to be examined to see the impact of the new information.

Secondly, outputs of one process become inputs to another process.

Finally, the processes can be done in sequence or at the same time, it really depends upon the process and the individual project. Nothing is siloed, each process works with another process to assure the plan is well defined to drive the project to completion.


Author: Elyse, PMP, CPHIMS
November 10, 2006

It isn't impossible, but it is definitely doing things the hard way. If you don't plan for something, it is definitely harder to make it a reality. Project planning is key to project management success. Planning allows for proactive decisions that enable the achievement of project goals. In other words, for project planning, just do it!

The five Process groups are executed in the same sequence for each project: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. They are all interrelated.

The Project Process groups interrelationships are listed as follows:

  • Iterating–It is often necessary to revisit processes. For example, the planning processes produce a Project Management Plan, but often, new information comes to light during processes of the Executing, or Monitoring and Controlling Process Groups that requires revisions to that plan.
  • Overlapping–Process Groups do not progress discretely. Various processes and activities within one Process Group are often occurring at the same time as processes and activities in other Process Groups.
  • Linking–Often, the output of a process becomes an input to another process within the same group, or to another process within another group.

Another key understanding is that the Planning Process group draws from the nine Project Management Knowledge Areas as follows:

  1. Project Integration Management–This includes the processes needed to ensure that the various elements of the project are properly coordinated. The planning process related to this knowledge area is Develop Project Management Plan.
  2. Project Scope Management–This includes the processes needed to ensure that the project includes only the work required to complete the project. The related planning processes are Scope Planning, Scope Definition, and Create WBS.
  3. Project Time Management–This includes the processes required to ensure timely completion of the project. The planning processes related to this knowledge area are Activity Definition, Activity Sequencing, Activity Resource Estimating, Activity Duration Estimating, and Schedule Development.
  4. Project Cost Management–This includes the processes required to ensure the project is completed within the approved budget. The planning processes related to this knowledge area are Cost Estimating and Cost Budgeting.
  5. Project Quality Management–This includes the processes required to ensure that the end result will satisfy the needs for which the project was undertaken. The planning process related to this knowledge area is Quality Planning.
  6. Project HR Management–This includes the processes required to make the best use of the people involved with the project. The planning process related to this knowledge area is Human Resource Planning.
  7. Project Communications Management–This includes the processes required to ensure timely and appropriate generation, collection, dissemination, and storage of project information. The related planning process is Communications Planning.
  8. Project Risk Management–This includes the processes concerned with identifying, analyzing, and responding to project risk. The planning processes related to this knowledge area are Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, and Risk Response Planning.
  9. Project Procurement Management–This includes the processes required to acquire goods or services from outside the performing organization. The related planning processes are Plan Purchases and Acquisitions and Plan Contracting.

Finally, the Planning Process groups contribute to the development of the Project Management Plan by assuring that all stakeholders participate. This action enables stakeholders to gather information and utilize that information to help develop plans and document procedures.

As new information is discovered, plans can be revised accordingly, so the appropriate steps can be taken to ensure the project's objectives and scope are achieved. These steps are normally defined by the project change control process.


Author: Elyse, PMP, CPHIMS
March 8, 2006

Ah the soft skills, the items that assist with project managment success but are rarely mentioned. Yesterday, I was presented with this listing, and I thought it was definitely worth sharing.

Twelve Rules for Project Management Success

  1. Gain consensus on project outcomes
  2. Build the best team that you can
  3. Develop a comprehensive, viable plan and keep it up-to-date
  4. Determine how much stuff you really need to get things done
  5. Have a realistic schedule
  6. Do not try to do more than can be done
  7. Remember that people count
  8. Gain formal and ongoing support of management and stakeholders.
  9. Be willing to change
  10. Keep people informed of your activities
  11. Be willing to try new things
  12. Be a leaders as well as a manager


Author: Elyse, PMP, CPHIMS
February 15, 2006

One of the activities on Monday, I attended was the Project Management SIG for HIMSS. I have come to the conclusion that it is time to start taking some action, instead of just lamenting on how misunderstood and underutilized this process has become.

When the opportunity arose, I joined the Executive Board. The obligation is minimal six 1hr meetings a year. What I am hoping to do is help layout the PM Sig Website into a repository for projects, applicable tools, and forums. A little community can go along way.


Author: Elyse, PMP, CPHIMS
February 7, 2006

Every so often, we need to have project status updates just to clearly identify who is doing, what and when, and how it is going. What is sometimes bewildering to me, is that although status updates are common place, they are perceived as an annoyance by the responsible parties.

So what is in a status update, at a high level, what is being worked on, what's next, and what was done. If you are on the end stage of a project or reviewing outstanding issues. A format that works for me is:

Issue Identification:
Summary:
Responsibility:
Current Status:
Next Step:
Accomplishments:
Decision:
Follow up:

It is a pretty easy format, and clearly describes responsibilities. Also it yields a useful summary of information of where the issue status.


Author: Elyse, PMP, CPHIMS
January 22, 2006

Project Management should be one of the hot topics for healthcare. The ability for health systems to be able to execute in a nimble strategic fashion is needed. Project Management is the tool in the toolbox that allows the ability to execute. Program Management or Portfolio management helps determine to which projects you make out the resource checks. The demand of the business community is insatiable, and rightfully so. There are numerous solutions that would enhance patient safety, quality of care, and the patient’s experience. There are PACs solutions, MAR, Order Entry, Clinical Documentation on the clinical side of the house. Obviously Wireless falls right into play here as does Remote Access. Decision Reporting from actual clinical data instead of revenue claims data would be ideal; however quality initiatives data normally comes from revenue data. Quite frankly, there is a lot that can be accomplished. The problem is accomplishing the activity with all of the operational maintenance that still needs to occur to existing systems.

Project Management helps to manage the implementation of the project. There is a plan of how to proceed from where you currently are to the desired state. Within the plan is a scope definition of what work will be accomplished this time. Work that is out of scope, can be handled by a scope change process. Questions, Problems, or concerns along the way are issues. Once there is a plan of what to do with an issue, add it to the work plan and close the issue.

Healthcare Facilities need to be better at managing projects in order to be able to accomplish what is needed to be done. However the management of a project is not the IT responsibility alone. It is across the board a partnership between the business and IT, not one vs. the other. Imagine the disastrous consequences of just allowing only IT involvement in implementing a clinical solution, or a revenue enhancement. Just on the lack of business buy-in to the solution it is bound to fail.


Author: Elyse, PMP, CPHIMS
September 11, 2005

In the process of deploying a new system, or if you are planning to deploy a new system, please take the time to set up a war room.

What�s a war room? A war room is a central location where members of the project team are available. These members man the phones, answer questions, take down issues, and work issues. It is good to have a war room staffed with whiteboards, markers, phones, and food. (people will be there for a while)

We recently deployed a system. The war room was a great addition for the project. Allowing for users to have a centralized place to call for help, and an atmosphere where people were working the issues down was very beneficial.

Another benefit was a daily status call, where the leaders of the project team called into discuss issues, resolutions, or common user mis-interpretation. It gave everyone a sense of urgency, and the project status. Also it was a known place to communicate with your teammates.


Author: Elyse, PMP, CPHIMS
August 26, 2005

The following is the list of components that should be included in a charter document. However, depending on project size and complexity, some of the components may be excluded while some unique sections can be added. The listing of components does not assume any set sequence to create the documentation. Each project may require different emphasis for different components, ie for one project the project organization may be the first aspect that should be documented, for another project it may be the milestone timeline. However, the executive summary should usually be the last section created.

  • Executive Summary
  • Project Goals and Objectives
  • Revised Scope and Requirements
    o should also include the current and �to be� state
  • Project Team
    o Identify the project organization, including governance, reporting, and escalation points
    o Define the project roles and responsibilities
  • Implementation Strategy
    o Timeline � Include at a minimum a milestone timeline, but may also be a project plan to the known level of detail. Should also include a resource estimate for both IT and user.
    o Contingency Planning � describe what the impact on the project would be if the proposed live date is not met
    o Deliverables � identify the known deliverables for the project (should be referenced in timeline)
    o Testing approach � at a high level, describe the testing approach that will be utilized
    o Training approach � at a high level, describe the training approach that will be utilized
    o Cutover � document the known assumptions, constraints and approach for production cutover, including any contingency planning that will be needed
  • Communication Plan
    o Describe how the project team will be kept informed. Describe how IT and user management will be kept informed.
  • Critical Success Factors
    o Identify the major risks to the project and how these risks should be mitigated
    o Include any revised assumptions and constraints on the project, especially if they are different from Phase 1
  • Issues list
    o Document any known issues. This should be the initial list that will be updated throughout the course of the project.


Author: Elyse, PMP, CPHIMS
August 23, 2005

Oh its a nice little word, but my is it a sigh of relief when completed.

Why the sigh of relief? Nerves? Not at all. For those involved directly, many long, hard work weeks, months are now turn into even harder, longer work weeks. Getting the final test cases validated is a difficult and time-consuming task. There are plenty of obstacles with the process.

But when you are done, you have the knowledge that all that is left is the live event. Issues will arise, but unit testing in most cases can resolve those issues. The obstacles jumps after acceptance testing are clearly defined with issues necessary for live, and post-live.

This is a milestone surely to be celebrated it is a golden event. The cumulation of a great team effort, because one never makes it to acceptance testing alone. The requirements have been met and we are moving forward, we are in acceptance state.

So as the time comes and passes remember the journey and the team the journey has created.


Author: Elyse, PMP, CPHIMS
August 22, 2005

I will soon be in the wonderful place of bringing another group through a chartering process. So before I begin this trek, let�s discuss what items should be in place before chartering begins. I�m discussing chartering a project right before implementation. At this point in time, there already has been the conceptual phase and the building/acquisition phase is completed. So what elements do we need in place before we can really start this endeavor?

First, a business case should be in place. This will have the high level scope and requirements. The proposed budget, assumptions and constraints, and resources needed.

Next, since you have acquired a system, a contract is necessary. A good contract leads to a good implementation. The contract will clearly state the statement of work, and deliverables. It will also include a highlevel timeline for implementation with timeframes. If you are good at negotiating, then also include payment after key deliverables.

So in summary items that need to be inplace before implementation contracting.
� Business Case
� Budget
� Contract
� Scope and Requirements
� High Level Assumption and Constraints (including any expected timeframes)
� High Level Resource statement (Stakeholders, departments affected)


Author: Elyse, PMP, CPHIMS
August 12, 2005

Issues Management on a large project is time consuming. On a project with a virtual team it is demanding, on a project with several virtual teams one really needs to have a web-based solution. Sometimes projects are implementation based others are build/construction based. I think there are different solutions available for both, but one that I have come across and happen to like is Eventum.

Why do I like Eventum? Well a couple of reasons, first it is very easy to use. With the pilot group consisting of the exceptionately computer literate to the "how do I use my mouse?", everyone was able to pick up Eventum with little to no training.

The second reason is that as soon as one logs into the product, there are analytics with where the project currently stands. Everyone can see who is overwhelmed, and what team needs to work down the issues.

Another reason is that one can have several teams designated for a certain project. Also one can have several releases for staged implementations.

There is also the history of how an issue was assigned and routed. Comments can be placed within the issue, and also documents of the problem at hand.

There are canned reports that are delivered with the system, and one can export issues to excel.

Now I know that with Eventum, it is not OOP. But honestly since I wasn't building it, that really wasn't a concern of mine. I also realize that with Eventum, others can change the notes. However, if you are that paranoid, maybe counseling is needed. Also Eventum is open-source, the install is a download away.

Individuals may have concerns about open-source software. There are many viewpoints on open source. Some individuals believe Open Source is the greatest thing on this planet. Others are cautious and risk-adverse of the open source solution. My concern with Open Source solutions derives from the need to be able to support it. Sometimes having someone to call or look to helps make a business case. I haven't found that party with Eventum yet.

When I went looking for an issue system, I was searching for a quick, easy to use, system implementation based solution with good analytics. Cost needed to be in the below $5000. Now we are looking at using a web-based issue system, but I'd like to offer up all solutions available. I know JIRA is a good system, but are there any others?


Author: Elyse, PMP, CPHIMS
June 24, 2005

After reading Peter Farrell's Mach II is dead, I think it is time that Mach II was released to the community instead of being the individual work of Hal and Ben. They have done a great job, but better project management needs to occur or MachII will fade away. First a project team structure needs to be set up, there should be an oversite group which included individuals such as Hal, Ben and Sean. This group ultimately approves what needs to go in what release and what ways to communicate to the general public. My next suggestion is to add a group of developers to do the building. Developers who want to contribute for the good of the framework. Also a team of documentation experts would do well to be apart of the team. A shortfall of the project is the lack of documentation; if the framework was for the community then there should be more documentation. A way for the community to contribute documentation, like MachII.info needs to be recognized.

The next big items needed are a schedule and a change control process. Please correct me if I�m wrong, but there are no schedules for improvement or change control processes. At first the change of the Mach II framework was rampant, almost 4 version changes in six months. Then there was 1 change within 6 months, and now nothing since October 2004. An anticipated release and functionality schedule needs to be shared with the community at least one that will take advantages of what has been offered with CFMX 7 and fix the plugin manager bug.

Thinking of the plugin manager bug, the other item that needs to be shared with the community is the bug list or issues. The issue list needs to capture what will be fixed, what won�t be fixed, and what doesn�t need to be fixed. This will give everyone a good sense of where the Mach-II project is at the current time. JIRA is available to most open-source projects for free. How many issues or bugs are there with the current Mach-II?

The final item is that throughout the project, there seems to be little or no planning to anything outside of the first code development, and this item is causing Mach-II to fail. There is no substitute to planning, and a project without planning will always fail. Good luck to Model-Glue to avoid this risk, just plan a little more communication, a schedule of releases, and a project team with community involvement.


Author: Elyse, PMP, CPHIMS
May 25, 2005

Let's take a moment to discuss risk factors, a friend of mine was nice enough to share his list with me yesterday. It is a good checklist of general risk factors. These are general items that if and when they hit a project can place you in the land of projects that headed south of the border.

Project Risk Factors

  • Lack of team skills and head count
  • Unrealistic Schedules and budgets
  • Developing the wrong software functions
  • Developing the wrong user interface
  • Gold Plating
  • Continuing stream of requirement changes
  • Shortfalls in externally furnished components
  • Shortfalls in performed tasks
  • Real-time performance shortfalls
  • Straining technical architecture
  • No or little planning


Author: Elyse, PMP, CPHIMS
May 21, 2005

GanttProject is a tool definitely worth its salt. This tool allows one to create a work breakdown structure in a clear concise manner. It allows one to visualize the project, and see the sequencing and dependencies. The other tab for resources assists in managing resource, which at times is a critical risk to the project.

The one problem with most PM tools that I have found is that there needs to be the level of detail wbs plan, and the high level milestone plan. This is still the case with this tool, but the cost of the tool is not very prohibitive.


Author: Elyse, PMP, CPHIMS
May 15, 2005

Had the meeting on Friday about the resource conflict. It was a good meeting, although I had a couple of revelations during the meeting. The resource hadn�t done an enough is enough in the team meeting as I had assumed. What actually had happened was this.

At the beginning of the month, I had scheduled a quick 30-minute daily build meeting between all building resources. The meeting was to create a time to chat for all builders, discuss issues and get quick status with where the project was and if the team needed anything. We meet daily, all via a conference line. This was people can also try something quick on the computer if needed.

I had made it my mission to type up minutes and distribute the minutes to the group and management daily. I tried to have someone else type up the minutes, but we don�t have that type of resource spread, or I don�t have enough pull with the secretarial staff. The minutes detail discussions, decisions, and next steps. They also plainly stated what was done and what was missed.

The problem is that this resource was overscheduled, and well the director finally realized it. I had asked for a full-time resource. I only got one dedicated 25% of her time. The resource silently worked a lot of voluntary overtime to get things to where they needed to be. So the director�s solution was to yank the resource for the other project, and offered no alternatives. Every minute that resource spends or doesn�t spend on this project directly either shortens it or elongates the project. The resource is working the critical path.

The other problem was with the design, even though the interface group approved the interface design. Now apparently, they need some training in how to do real-time hl7 charges to a file within Open Link.

My main problem with this situation, is that I was offered no alternatives and the situation wasn�t set up to be a negotiation. It was leave me scenario, and now I�m trying to brainstorm as to alternatives so the project once again isn�t held up. When the resource risk hits, it sure expands the project timeline.


Author: Elyse, PMP, CPHIMS
May 12, 2005

Boy, I could see this one coming a mile away. Too many chiefs, too little injuns, and not enough of resources to go around the posy.

When I first got the resource, I explained that there would be a problem. That other project needed to be redirected to another person. This project needs to get done or we severely impede the billing process come the new grouper in the fall. The timelines between the two projects aren�t compatible. The resource though is phenomenal. She still actually cares about doing things right for the right reasons. Her work is of high quality and well documented. She believes in a good QA process through out the project.

But, the management wouldn�t redirect the other project, too few qualified injuns. We have been a couple weeks into the heavy build of my project and the cross roads have come to bear. I could see it happening for the past couple of weeks. The person was just beginning to overly organize her time, and her stress level was going up. The daily team building meetings didn�t help the resource�s stress level, but the build is going good. Now, I�m getting the term bulldozer applied. It�s a running joke, but it is honestly time to drink the kool aid.

So now we have an emergent meeting, because the other project needs time. My guess is at the team meeting with the functional director the resource kinda went with enough is enough. Its near the live time of the other project. We all know that the other system�s live, is not going to yield productive build time for my project. We also all know that without productive build time, my project is going to be delayed.

As PM, there are many times when I just wish we were a project base organizational structure instead of this functional based. The resource risk would be eliminated, and things would be better. Its hard trying to get a project done without resources. The project simply does not get done. In this case, that just isn�t acceptable.

Sometimes I miss a life without the political intrigue.


Author: Elyse, PMP, CPHIMS
April 26, 2005

Scope creep is a great and vile thing. Its great because enthusiasm is occurring and people are wanting to do more with the project. It is vile because it has a potential to kill the project timeline, budget, and bring unjustified risks.

So how does one handle the ever challenging scope creep as a project manager? First, its best to have everyone know what has been committed to for the deliverables. A high level deliverable overview with the team is always a good thing. Next, clearly define how to change the scope of the project within the project organization for example.

First, there needs to be a change sponsor, who is responsible for quantifying the change. They should be able to produce a document with the change described, the impact of the change to timeline, budget, any new risks of the change. The benefits and disadvantages of the change.

This document then needs to go to the leadership group for finalization, here the pm endorses the change, the project sponsor endorses the change, and the executive sponsor endorses the change. At this point the scope creep is a managed change. Now some changes are no-brainers, others appear to be no-brainers but have hidden impacts. This basically gets everyone on board with a way to make changes occur to the project scope after the project has been defined.


Author: Elyse, PMP, CPHIMS
March 30, 2005

Here's the scenario, we are putting in a system. I got in on the project very late in the game. So I'm sitting in my cube last night, just about ready to leave and enjoy the first sunny day in recent memory. I'm going though my voice mail, and I have a call to place. I'm talking to the person, and she is listing to me all the remaining items that need to be done. Do you have an list of this stuff electronically? I can take a look and see what we can farm out. Let me finish putting one together, and I'll email it to you.

I know issues lists are a pain if you are in the front-line of a project. They seem to take time from the project and why are we wasting the time, instead of just getting it done.

Well, the truth of the matter is that you end up being too close to the problem and at the end of a tedious project, let's face it, you are worn out. The issues list helps to quickly categorize what needs to get done. But that is not really enough, one needs to have categories together like. Priority is this critical, high, medium, or low. Is this needed for live, or can it be added in shortly thereafter. Who is responsible for this issue, and if needed what team does this issue belong too.

I dislike maintaining issue lists, but it is a necessary evil to getting a project completed. It is also a blessing in communicating and managing a project.


Author: Elyse, PMP, CPHIMS
March 29, 2005

Oh the big bang approach, one has to hate it. I remember my first big bang approach a couple of years ago. At the same time we replaced the hospital registration system, interface engine, and implemented a clinical repository. It was several weeks in June, and during that time I got reassigned from the night shift to the day shift. We were staffed for the bang, had a team of consultants on site, IS support was around the clock. People where positioned on the floors. In house registrations were manually transferred from one system to the new system. Oh it was an experience. It has tainted my attitude towards Big Bang implementations.

If I have a preference, and I will strongly argue my position, I like phased implementations. It keeps the deployment manageable. The resources are dedicated to the department or system at hand, not thinly spread across the board. The risk factor is less simply by not implementing the all inclusive solution. One can carefully maintain monitors and trouble shooting is simpler. Plus by phasing in solutions, skeptics convert to true believers.

The only advantage in the big bang is that it gets it all done at once. However the support after live is probably longer than the phased implementation.


Author: Elyse, PMP, CPHIMS
March 22, 2005

Our organization is moving towards a project management organization. One of the steps of this process, is that for all IT related projects there is a project summary bulletin board or dashboard to be correct. On this dashboard, we have a bi-weekly summary of the projects that are capital projects, meaning someone budgeted money for the project and the money got approved. Currently, IT just fills out the list, I believe it needs to be a responsibility of the entire community, but that is just my conjucture.

Any way, the list is now being rigorously reviewed. There are three categories:
Green - good life is great
Yellow - warning caution problems exist
Red - we are a ship that is sinking over here

Anyway, yesterday was my time to review the project list with the new keeper of the data. I have a couple of projects and they are in various green stages. However, I was lucky enough a couple weeks ago to inherit another project that was yellow (really red). The problem with the project is that there are two different camps that believe there are two different levels of work. So we are in the process of negotiating with the two camps the work needed to be done, and when resources will be available. This is a political process, not one that really can be captured in the light of green, yellow, and red. The fact that we were actually talking on what needed to be done, and not firmly entrenched in camps, I put the project to green. Explaining that to the new keeper was just funny, never really ever saw a look that captured the facial expressions of being perplexed, so wonderfully.

I guess, in places where project management is actually a practiced discipline this makes no sense setting the project to green. However, here at the newbie growing stage there needs to be a clearly defined set of requirements that states the colors of the stop light. This way when the colors are set the criteria is the same.

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



Author: Elyse, PMP, CPHIMS
March 17, 2005

I have a problem, it has to do with audience and the understanding of a project plan. It�s a complicated plan, we are basically phasing out one system, replacing a new system, and adding 3 departments to the new system with new applications, new workflow, and new billing and decision support interfaces. Complicated project, Complicated project plan. My organization is new to understanding things as projects.

I�ve been using MS Project and it seems to work well for me, but the project team, and the business leadership group aren�t embracing it. My co-PM, the business PM, wants to get the project plan into excel for the team leads. It�s a 26 page project plan in project, and I believe a lot of interdependencies will be lost in just showing the team leads the task list in excel. I�ve printed the PERT chart out of project on plotter, and once again everyone was scared by the amount of work. I did an overview, high level roll up and again why so long?

I need to get the audience to understand the project plan, and the amount of work effort needed to complete it. They also need to have a sense of ownership for the project plan. (Especially since they will be doing a lot of the work, and they already have fulltime jobs) Anyone have any ideas?


Author: Elyse, PMP, CPHIMS
March 13, 2005

At work, I�m involved in a project to implement a new coding and abstracting, case management, and quality management system. This will replace pre-existing custom db applications and the vendor supporting coding application. In my opinion, it has been a difficult project to get started due to the lack of a pm from the business community. We have been starting a new practice to have projects jointly managed by a business pm and an IT pm. One of the critical items in this pattern is to ensure both project managers actually are dedicated 20 � 40 hours a week to the project. For the business community, they have hired a consultant pm to take this responsibility. So far this has been a good move having the project jointly managed, because it has brought several key items to light.

For example, being from the technical side of the house, the draft work plan was drawn up with mainly a technical focus, with input from application analysts, interface analysts, and network engineers. There were a couple of key items, which the business pm immediately brought to light.

First, the training needed to have a competency assessment completed at the end. This is to ensure the material was digested an understood. Also a remedial training class must be created, and a plan of action for those individuals who are unable to pass the remedial class and training class.

Second, for all new workflows, not only must operational flows be documented, but new policy and procedures need to be created. If these policy and procedures are cross departmental, a cross departmental review and approval must occur.

Third, cutover policy and procedures also need to be created on the departmental level.

The good thing about these additional tasks, is that it always goes to show more heads are better than just one. People make plans based upon their experiences, and the plans improve if it comes from everyone. The business pm and myself are reviewing the project plan with the entire team next week. The goal of the meeting is to discover any additional tasks and obtain the duration of a task from the individual responsible for the task. It should be a very good meeting.


Author: Elyse, PMP, CPHIMS
February 8, 2005

There are times, I just want to get back to doing the actual work at hand. We are currently in the planning stages of a new project. Yesterday morning, I had the unfortunate experience of scheduling a meeting to decide who is going to do what on a project. The meeting was bright and early on a Monday morning 8:00 am, several VPs and several directors, but a small enough group to actually get a decision made. In my youthful exuberance I thought.

First thing out of the box, the new and improved charter was never received before the meeting, although it had been promised by a director. The old one, which was incorrect, was handed out. Next came the voicing of complaints on the early hour of the meeting on Monday morning. I sat and quietly nodded my acknowledgement, however in my organization it is impossible to schedule this group of people at a better time without 2 months notice. It was 8:00 am on monday or 7:00 am on Wednesday. Trying to get back to the schedule at hand, which was the project organization structure again was lost. One VP wanted something fundamentally this way, the other vp had an opposite opinion of the fundamental belief. Neither philosophy had to do with the project team organization. We tried getting at the project organization from a top down structure, failed miserably, then we tried from a bottom up structure. We were slightly more successful. We stopped at the project manager and decision makers. No one wants to lead the middle but all what to participate. After the meeting, I went to one of the director�s office, and wouldn�t leave her alone until we actually had an agreement on the project organization and structure. We also banged out what each team would be doing, we have teams for reporting and converting, intersystem workflow, technology, case management, quality management, coding and abstracting, and 3rd party denials. I understand that planning is needed. We as an organization need to know where we are now and what we do, then how we will be functioning and then figure out how to get there. But if it is taking 4 weeks to get a project structure and organization, how long is it going to take to plan what needs to be done? Of course if we don't plan, is there a less chance that the pieces will fit?


Author: Elyse, PMP, CPHIMS
January 31, 2005


We have all been there, asked to do a project that we think why in the world do they want to do that instead of this. Or we have had the other extreme anxiously waiting at the bit to do the latest and greatest, but being told this isn�t where we are extending our resources at this point in time.

The truth of the matter is that if you work for a corporation, someone has to agree and bless the work you are doing. In other words sanction that it is ok to go down that road. If you are working on a project that isn�t sanctioned by the powers that be, that project has one of the main factors of failure.

Taking a step back there is some key information that is needed so that the project does get blessed. First, there has to be a realistic business problem defined and quantified, and the picture of the future state needs to be explained. For example, wanting to place an rss feed on the what�s new is cool, but what problem does it solve? However, allowing a way for employees to receive instant updates about media news, may be a good use of resources, but having an rss feed of new PACS images with the archaic PACS system is probably not fruitful. Another factor is realistically guestimating the work effort needed. Back to our example, the rss feed may be simple, but pushing a news reader to 1300 desktop may be a bit more work. Along with guestimating work, estimating impact on networking, hardware, systems, and process is needed. The information on all of the above, gives an idea of what the project will do. With this information, the sanctioner can make a good decision, and the project will be well on its way.


Author: Elyse, PMP, CPHIMS
January 20, 2005

A couple of tips to managing the critical path of a project:

  • Determine and group the risk to the critical path such as cash flow rate, skills inventory, flawed deliverables, configuration management and change management.

  • Establish a proactive process to manage the constraints on the critical path, this helps to ensure resources, materials, and facilities are available when needed on the project. Identify which critical path the constraint affects, there may be many, and remember to prioritize the constraints

  • Ensure that the skills needed for the critical path are available, if not set up a knowledge sharing process.

  • Any critical path risk should be in the risk management plan and risk log with the appropriate allevaition pattern

  • Establish a communication channel and schedule to handle the management of the critical path

  • Manage the critical path timeline, so that any slack time can be utilized. In other works, move it up the chain if at all possible so everything isn't waiting for the last minute.

Author: Elyse, PMP, CPHIMS
January 20, 2005

Cost Performance Index (CPI) is the ratio of costs budgeted to perform the work to actual costs to perform the work or BCWP vs ACWP. The formula is CPI=BCWP/ACWP. A CPI greater than one indicates a favorable result or cost under-run. A value of less than one reporesents a cost overrun. The use of CPI and CV calculations help IT project managers to ascertain if the spending trend is positive, negative, or neutral in relation to the work performed.

Cost Variance (CV)is the difference between the costs budgeted for an activity and the actual cost to finish that activity. The formula is CV = BCWP-ACWP. A positive reult indicates that the project in under budget, and a negative result means that the budget is overrun.


Author: Elyse, PMP, CPHIMS
January 20, 2005

Schedule Performance Index (SPI) is the ratio of work accomplished versus the work planned. The formula is SPI = BCWP/BCWS.

Schedule Variance, is the measured difference between the planned or scheduled activity duration and the actual activity duration. It is the difference between the Budgeted Cost of Work Performed (BCWP) and the Budgeted Cost of Work Scheduled(BCWS). The formula is SV = BCWP-BCWS. A positive SV indicates that a task is ahead of schedule and a negative SV shows that a task is behind schedule.

In MS project, Select the Gantt Tracking, then View -> Table -> Variance.


Author: Elyse, PMP, CPHIMS
January 20, 2005

Earned Value Management (EVN) is a management technique that relates resource planning to schedules and costs in time-phased increments. It allows for accurate assessments of status to date and is utilized to calculate estimates to completion of project.

Earned value refers to a cost-based performance measurement that compares the amount of work that was planned with what was actually performed to determine if cost and schedule are proceeding as planned. Earned value analysis provides a more accurate view than looking at cost or schedule variance separately. This information alerts the corrective action that must be taken to complete the project successfully.

The elements of earned value:

  • Budgeted Cost of Work Scheduled (BCWS) The estimate of costs needed to complete the scheduled project work.

  • Budgeted Cost of Work Performed (BCWP) The estimated of costs for work actually completed. Also know as Earned Value.

  • Actual Cost of Work Performed (ACWP) The cost of completing the project work

To calculate earned value:

  1. Calculate the Budgeted Cost of Work Scheduled (BCWS) for a given period. These amounts were determined when you develop the project budget and should be available from the baseline in MS Project.

  2. Estimate the percent complete of the work scheduled for the given time period.

  3. Calculate the Budged Cost of Work Performed (BCWP), or earned value, for the same time period by taking the percent complete of work times the BCWS.

  4. Calculate Actual Cost of Work Performed (ACWP) for the same period by determining the actual amount of money that has been spent on the work for this time period

In project to see this by a cost per task. Select the Gantt Tracking, then View -> Table -> cost


Author: Elyse, PMP, CPHIMS
January 19, 2005

Here is a quickie guide to for a communication plan


  1. Define the communication audience.

  2. Determine the content and frequency requirements for the audience, consider separate documents for the sponsor, stakeholder, supplier/vendors, and others.

  3. Identify special communication requirements of non-collated and international teams.

  4. Plan performance reporting and set expectation regarding the communication process

  5. Identify communication channels possibly your organization has a predefined policy

  6. Assigned who and how is going to communicate

  7. Schedule the time for communication (ensures it gets done)


Author: Elyse, PMP, CPHIMS
January 19, 2005

Project performance reporting refers to disemminating project performance information. Reports need to provide info at a level of detail appropriate for the audience. Sometimes these reports include a Gantt chart, S-Curves, and histograms.

The type of performance reporting are:

  • Status Reporting - an analysis of the current state of the project, any variances within either schedule, budget, scope, resources, quality or risk, also include the next steps of the project.

  • Progress Reporting - a report of what has been completed

  • Forecasting - How the project is expected or forecasted to perform in the future.

Author: Elyse, PMP, CPHIMS
January 18, 2005

A project is schedule-driven when the final delivery date is the overriding constraint that the sponsor or customer has expressed. Schedule-driven projects will consume whatever resources are required to ensure delivery on the established.

A project is resource-driven when the availability of resources, particularly skilled resources and costs, is the overriding constraint that the sponsor or customer has expressed. Resource-driven projects must expand time or sacrifice quality to remain within the constraints of the resources.


The constraint of schedule-driven or resource driven governs the decision of the project.


Author: Elyse, PMP, CPHIMS
January 17, 2005

Feasibility analysis determines the likelihood of project success. It requires that all elements impacted by the proposed solution be studied.

To perform a feasibility analysis, a couple of guidelines to follow are:

  • Make sure that you have addressed any regulatory constraints by researching industry or government regulations that apply. Examples are Federal Regs, OSHA, FCC, Dept or Transportation, and Dept of Labor

  • Pay special attention to cultural achievability of the proposed change. One idea is to ask the stakeholders if the organizational changes required for the project are realistic

  • Remember to use Subject Matter Experts, SME, when needed in order to ensure that all systems impacted by the project are catalogued

  • Take a careful look at the stability of the technology. Ask yourself whether or not the identified technical requirement are based upon technology that is operationally stable, available, and affordable.


Author: Elyse, PMP, CPHIMS
January 17, 2005

On the technology side of the industry, if you see an opportunity for improvement on a project. There are a couple of things that need to be explained when asking to change the directions.

First, an accurate measurement of the current conditions and circumstances that are based upon facts. With a clear statement of the opportunity.

A clear criteria of the resolved state, and what criteria will define success.

An analysis of the people, platforms, and process issues involved in moving the opportunity through to completion including impact analysis.

And the benefits that are gained.


Author: Elyse, PMP, CPHIMS
December 18, 2004

Accessing risk from projects is an activity that needs constant vigilance. When evaluating risk, examine the probability that the outcome will occur, the various possible outcomes, when this risk is expected, and how often it will occur. Risks have some of the same patterns.


  • Schedule Risks

  • Cost Risks

  • Quality Risks

  • Scope of Work Risks

  • Resources Risks

  • Customer Satisfaction Risks


During the project, in all likelihood, all of these risks will surface in one fashion or another. There are different ways to manage risks.

  • Avoidance (reducing probability): You can avoid a risk by eliminating the cause of that risk.

  • Mitigation (improving alternatives): You can achieve mitigation by reducing the probability of the risk outcome while increasing the likelihood of a good outcome.

  • Transferring (reducing impact): You usually do this by creating insurance of some kind that involves assumption of responsibility by another party.

  • Assumption (acceptance): For risks that have a low impact, accept the risk and create a contingency plan.


Author: Elyse, PMP, CPHIMS
August 23, 2004

How far are you along with that task? Are you 50% done, 60% done, 77.77777% done? I hate this question, and after a little research I think I've come across an idea I like alot more.

We often have to do progress reporting for a task, and then estimate the percent complete for the task. This is a time consuming exercise riddled with unintentional misconceptions. Well, functional testing is 50% done, but we still have to test the other half of the application. Whose to say that half won't take twice as much time if a major issue is uncovered?

So what's the solution, it is pretty simple. There are three rules, 50/50, 20/80, 0/100, here is how it goes. For the x/100-x rule, when the task starts it is immediately completed by x percentage, only when the task is completely finished and closed out it gains the remaining 100-x percentage.

So for instance, for the task of functional testing, as soon as we start we are 20% complete. We maintain this status until we have completely finished functional testing, and at that time the task becomes 100% complete. A much more systematic method than random estimating.


Author: Elyse, PMP, CPHIMS
August 17, 2004

The "not invented here" syndrome hits alot of different places in different ways. In managing projects, one of the very first steps should be to look at other previous projects for something similar. It just saves alot of time and headaches in learning from others.

The creation of and maintainence of a project repository is just very very useful. It also shouldn't be locked away from different groups. If you have a functional organizational structure, different groups should be able to see others projects.

What is in a project repository? Well it should contain the project plan materials items. A good items is to have the charter, risks and issuesl, the schedule with slippage, scope of work, work breakdown structure, the change control plan, how communications where handled, what the risks where, and the budget for the project. Any correspondence regarding the project should also be maintained within the repository. Also the estimates and resources needed for the project. One of the more important items, is the review of lessons learned from the project.

So once you have the repository in place, use it. Its best to start first thing in the initiation phase, look at what has been done and what worked. look at what didn't work and if applicable apply the recommendations to the new project.


Author: Elyse, PMP, CPHIMS
August 14, 2004

Who are stakeholders in project management terminology? A stakeholder is someone who is affected by the project or someone who affects the project. So who are these mysterious stakeholders?

There is the project manager, this is the individual responsible for planning, communicating, assigning tasks, gathering identified issues, ensuring there is quality to the project, coordinating training on the project, tracking the benefits of the project, and providing the deliverables are on time. If it is where you make your bread and butter, you are affected by the project.

Another stakeholder is the customer or business associate. This is the group who will actually use the end result of the project. We are all affect by something that is going to change the way we work.

The project sponsor and executive sponsors, who provide the money for the project, are obviously stakeholders. I think we are all affect by our money is going.

The project team are all stakeholders. This is the group of people who are working on the tasks of the project. Interest arises from this is either work to be done, or work in progress. The work that needs to be completed affects those who are doing the work.

Now here is the political trick, let�s say you know someone who is none of the above, and yet still influences the project. Guess what another stakeholder has been identified!

A tip to stakeholder management, and i know it is anal, is to keep a matrix like the one below. It really helps if you need to turnover the project, get new manager, or some other reason you start getting asked why?

Stake Holder

Organization

Department

Project Role

Role on the project

Knowledge Base

Area of Expertise

Skill Set

Their skills

Project Need

What they need or want from the project

Personality Style

Detail out the personality style. ie difficult, likes to always be right and on top, best investigator i know.

Interest Level

Very high, high, medium, low

Influence Level

Lay it out on the table. ie can bring project to a grinding halt if concerned.

Communication Plan

Plan how to work with the person

Frequency

How often

Lessons Learned
Label what you have learned from working with this person



Author: Elyse, PMP, CPHIMS
August 11, 2004

Scope changes happen all the time, its a part of business. What we do is not an exact science, its difficult to calibrate. There are repeatible processes, but we aren't in the business of making 1000 lightbulbs. We are in the business of delivering technical solution to make the business run.

So when one has a project, and a change occurs, don't stone wall every one about the change.

Just simply quantify it, state the impact on the duration of the project, any new risks or issues that arise, if the cost of the project is increase and the impact of that upon the budget. Also clearly define the business value of this change.


Author: Elyse, PMP, CPHIMS
June 19, 2004

As of 6/15/2004, there are 844 members in Healthcare Project Management SIG. In addition, as of 2002, there are approximately 5,794 hospitals in the US. So here is an interesting question, since America is moving forward with an electronic healthcare record. How are we going to implement it if so few healthcare institutions are interested in project management? (Assumption being, the members of the Healthcare project management sig is indicative to those interested in PM)


Author: Elyse, PMP, CPHIMS
June 6, 2004

The conceptual phase of the project lifecycle defines a the project, so management can decide to pursue or not. The purpose is to yield the tools, so someone can make an informed decision and envision the project's intent, scope, benefits and costs. There are several tools that can be used to paint the picture for executive management.

One of the first items that needs to be completed is to determine what is required, needed, and or desired. This is done with simplified use case modeling. Discover the actors, their functions, and goals. Detail these use cases in simple paragraphs to capture the essense of the case. (More elaborate use cases are completed as a part of the building phase of the project)

As you are discovering the intented usage of the system, it is a good idea to start a risk list, and how you intend to manage each risk. Its best to identify and start working on risks in the beginning instead of the end.

Since no one really referrs to the same term in the same manner, another item to have is a glossary. This will help to define terms. I'm not familiar with other industries, but in healthcare there are several ways to refer to the same thing. For example the unique number for a patients visit can be either serial number, patient case number, encounter number, account number, and so on.

After establishing the use cases at a high level, it is time to create the vision document. This document has many components to capture the intent of the new system. One part details the problem that is at hand in terms of the root cause. Normally for technology business cases, the problem is a business processing problem for which a technology solution can help or eliminate. Another part of the document details the stake holders. This defines who will be affected by the proposed project and how they will be affected. The document also includes a portion which covers the functional requirements of the system.

If you think the vision statement just isn't clear enough, sometimes a prototype can help to illustrate the solution. This isn't a defined deliverable, but if you believe it will help to illustrate the point. It may be worth the time to invest.

Another deliverable is the implementation plan or software development plan. At this point, it is high level, but it does capture the needed resources, and time for tasks within the project. Its a work breakdown structure with people assigned to the tasks.

After there is a clear understanding of the vision of the system is going to be, the next document that emerges is the executive summary. This document provides a high level overview of the key findings and recommendations. It is also summarizes the current situation and the future if enhancements go as planned.

Finally the business case takes all of these components, and analyzes them in conjuncture with the total cost of ownership, including both one-time and recurring operational costs. The business case includes the executive summary overview, the risk list, functional requirements, the resource costs, and the vision of the new system. It is probably ideal to have this in a format that can be used for multiple projects so they can be compared to one another.

The business case should be the comprehensive document that allows executive management to decide the feasibility of the project.


Author: Elyse, PMP, CPHIMS
June 5, 2004

There are a lot of proclaimed fixes to the high failure rate of project in technology. The rate of failure for a software project is exceptionately high, sometimes quoted at 35%. Before looking at a solution to project failures, I think one really needs to understand the intricacies of the project life cycle.

Projects are comprised of four phases: the conceptual phase, the development phase, the implementation phase, and the termination phase.

The conceptual phase defines the scope, timing, and cost of a project. The business case, requirements, and resource need are completed within this phase.

The building phase comprises the designing, construction, and testing phases of the software, entails defining how the system will be used and training the users on the system, and constructs the live planning. The majority of the implementation costs are consumed here.

The implementation phase is the rolling out of the system into production. Items to be considered are the live event, ensuring there are enough resources, and how to address daily live issue management.

The termination phase of the project lifecycle is concerned with the turning of the system over to the supporting organization. Another essential item in this phase is a review of the project to learn from successes, and mistakes.


Author: Elyse, PMP, CPHIMS
June 5, 2004

The triple constraints in project management refer to the scope, time, and cost constraint of any project.

The scope constraint details the project requirements against the existing need of the project versus the expectations.

The time constraint addresses the timing and length of the project.

The cost constraint defines the total cost of the project both operating and implementation costs.