While most healthcare organizations have accepted the need for project management, many are continuing to face problems with the over-allocation of resources and unfocused project selection.

Why?  Because you can’t effectively manage projects in a vacuum.  Project Portfolio Management (PPM) is critical for success.  PPM ensures projects are objectively selected, prioritized and tracked.   It allows for a holistic view of the organization’s goals and resources and provides a roadmap for leaders.

Management of the portfolio is an ongoing process.   Leadership must continually review the portfolio and decide if each project is still worthwhile.  Cutting a project shouldn’t be viewed as a failure if it is determined to no longer be of value to the organization.

Most organizations end up with too many projects underway, but achieving little of real value. Another benefit of PPM is the ability to view the organization’s resource allocation. Without PPM, you are unable to determine how many projects are currently underway and if there are adequate resources to complete the projects on schedule.   The project portfolio is also helpful in assessing and managing project risk. 

How do you move from project management to PPM?

1. Establish a project management review and selection process.
2. Compile a project inventory and create an enterprise resource pool.
3. Prioritize projects based on the organization’s strategic plan.
4. Utilize PPM software such as Microsoft’s EPM Solution.
5. Model your resource demand, capacity, and utilization.

Organizations utilizing PPM have seen a reduction in implementation time and expense and improved quality. PPM allows management the opportunity to think strategically about each new project and make informed decisions for the organization.

Healthcare is in the midst of an IT revolution and project management is quickly being recognized as a vital element for organizational success.  

Because of an increase in large and costly implementations, healthcare IT departments are training staff as project managers, or are actively hiring skilled project managers.  Many organizations are creating job positions for project leaders - a fulltime position dedicated to project management.

According to a recent article by Betsy Hersher and Linda Hodges, published in ADVANCE for Health Information Executives, “. . . healthcare IT vendors and consulting firms are aggressively hiring and training project managers to meet their clients’ growing needs.”  They go on to say that Project Management Professional (PMP) certification is becoming a must have credential for today’s IT professionals.

An informal poll taken at the 2005 HIMSS Project Management Special Interest Group meeting supports this claim - one-third of the 80 members in attendance were certified PMPs. 

Healthcare organizations are also recognizing the value of the project management office (PMO). PMOs can be as large as a dozen members, or as small as one. Some PMOs are utilized as a consulting resource for IT professionals leading a project, others manage all projects.

In the future, the PMO will not just be for IT projects, but for all business projects within the healthcare organization.  These projects will be either strategic business projects or quality driven projects and IT will simply be a part of the solution.

For now, IT will be leading the project management revolution in healthcare.  If you are in IT and see project management as a career, the future holds great possibilities.

Enterprise Resource Outline Code 30, commonly called Resource Breakdown Structure (RBS), can be used like any other outline code, but within Project Server, it has special functions.

RBS is a hierarchical code used to define the relationship between resources.  An RBS generally falls into two types.  The first and most common is an organizational-based RBS. The organizational RBS closely mirrors the structure of the organization and includes a company level, divisions, departments, workgroups and one or more resource levels.

The second is a geographic-based RBS.  This type is typically used when the primary concern in assigning resources is the geographic location of the resource. The RBS can be used to determine user rights for:

• viewing, changing and assigning resources
• resource sharing across organizational boundaries
• timesheet approval
• viewing projects.

Generally, the RBS works best as an organizational structure, but there are exceptions, such as when a PMO exists and needs access to all resources and projects.  In this scenario, the PMO structure may be placed higher in the RBS than it would appear in the corporate organizational chart.  

In organizations which reorganize often, but leave managers over the same staff, choose the hierarchy based on managers.  If your organization commonly shuffles managers around, but maintains the same departmental structure, choose the departmental hierarchy.  

Defining the RBS depends on which of the following are most important to your organization:

• process for assigning resources, i.e., functional mangers vs. project managers
• organizational structure
• geographic location of resources
• ability to do skill-based resource planning.

I place a great deal of emphasis on RBS during implementation, because no other setting or field in Project Server has such a profound affect on the outcome (both positive and negative) of an EPM deployment.

Organizations must structure the RBS to mirror their organization’s requirements and project methodology.  Those who take the time to hash out the questions that RBS design brings will be rewarded.

Troy Wheeler, Vice President of Technology, EPM2e, can be reached at 800-878-0385.

Are you constantly struggling with getting your project teams and stakeholders to accept any responsibility for their projects?

This reminds me of the song “I Have the Project Accountability but No Team Authority Blues”.  Well, if it is not a song, it should be.  This is a classic dilemma that most project leaders face.   One of my favorite techniques is to let the team and stakeholders define their roles and responsibilities.  Here’s how I approach this:

I call a meeting with my project stakeholders and I ask this question, “How would you like to participate in this project?” Often I get the deer-in-theheadlight look and I usually need to follow-up with another question, “Would the group like to define the project requirements and specifications?”

They almost always respond positively.  I then write that on a flip chart as a bullet item.  I then ask, “How else would you like to participate?” If necessary, I’ll answer for them again, “Would the group like to sign-off on the project before going live?”

Again, I usually get an affirmation and write it on the flip chart.  Again I ask the participation question.  At this point they get the idea and the flood gates open with many ideas. Typical responses are: define the workflow, be involved in testing, help select the vendor, conduct training, identify problems, create solutions, communicate, and so forth.

What is the benefit?  Instead of me handing out a list of roles and responsibilities, the stakeholders create their own list,  take ownership and buy-in to the process.  I also memorize a list of roles and accountabilities that I want them to define in the meeting.  If they don’t hit one the items on my list, I ask the question, “Would it be helpful if you could (fill in the accountability or role)”. 

You can’t memorize a list?  Write your list in light pencil on the flip chart.  The team won’t be able to see it from a distance. 

You can also do this exercise with the IT project team members, or do it with both groups together.  It’s very interesting to see the different views on each other’s perceived responsibilities.