Author: Tom Flynn

Validating Project Management ROI: Looking Beyond Skill Sets and Competencies

Written by Tom Flynn on September 16, 2014. Posted in Articles. 6 Comments on Validating Project Management ROI: Looking Beyond Skill Sets and Competencies

This article has been written to illustrate methods that can be used to validate a Return on Investment (ROI), looking beyond skill sets and competencies.

Generally, organizations that engage in a formal Project Management Training Program will look to validate their investment by initially assessing a marked improvement in individual participant skill sets and competency advancement. This is, however, only an initial benchmark of effective project management training and the integration of raised personal attributes and cognizance.

The real test of the validity of a program lies in the participants’ ability to return to the project management environment and make a day-to-day difference in their actual project assignments. This can be measured, stratified and sold by utilizing two different mindsets/methods.

The first mindset/method, best used by an organization that is employing a definitive and mature methodology (defined as a methodology in operation and successfully in use for more than 2 years), would be to target the areas that comprise their key process indicators (KPIs). These areas would be determined by tracking actual project data over the methodology maturity life cycle, i.e., bolstering the skill and competencies that would
make the most positive difference in day-to-day implementation of the definitive methodology.

The second mindset/method would be to utilize the training program content (driven by pre- training interviews) to highlight areas in which the organization is currently taking the most hits on projects. This would include the full range of time, cost, human resource and management issues. The training, in this case, Advanced Training, should target specific solutions to these hot spots and, in effect, create the initial benchmark or key process indicator (KPI) targets against which to track. In doing so, the training would go beyond advanced general topic training to customized course(s) for implementation of the required process steps espoused by the organization.

This would serve as the beginning of a continuous improvement mechanism (the methodology) that can be owned by the project management resources.

Typically, organizations categorized as Level 1 or 2 in a PM-Capability Maturity Model (CMM) schema (either formal or informal), usually have not been tracking projects to a sufficient depth to create any form of accurate and meaningful benchmark/baseline data. The training program development schema, as designed above, would help to establish the initial target baseline that should be monitored at intervals determined prior to the training.

A few scenarios may arise from this approach:

Minimal improvement is detected at the first few milestone/review intervals across a wide range of pilot projects, and the participants are at a loss to explain the situation (no increase in cognizance). This would require an examination of the program goals developed from the participant and management anecdotal experience. The current day-to-day situation on the projects would also be reviewed (i.e., are the scenarios/hot buttons accurate and in alignment with those utilized as course drivers? Did we utilize the wrong targets or the wrong opinions/input?)

Improvement has been detected at the first few milestone/review intervals across a wide range of pilot projects. The participants have additional information as to where there are “roadblocks” (process or organizational) to further applying the skills the program targeted and transferred (increase in cognizance). This situation, although not exhibiting marked or substantial improvement, is very favorable, as the participants have
been active in the implementation of the program’s information. Through a level of raised cognizance, they can identify improvement opportunities ahead of them.

That being said, one must then analyze the improvement opportunities for real and substantive issues versus the possibility of identifying further excuses for lackluster performance. If you are working with an outside entity to assist your efforts, it is important you are involved in this process, as you know your team best.
An important piece to mention is that once the real and substantive issues have been identified, the organization should develop a positive response and implementation strategy, including a timeline, to clear them up. If not, the effort will be unsuccessful as the participants may feel as if “they [management] were trying to fix us rather than educate us to recognize what is and is not working.”

The last scenario is that marked and substantial improvement is detected at the first few milestone/review intervals across a wide range of pilot projects and the participants have additional information as to where other improvement opportunities are available (increase in cognizance). As previously stated, we would then analyze these areas of possible improvement for cost of implementation and value of return. This is slightly different from above due to the fact that in this scenario the “bleeding” has stopped, and the project is in far better shape. We therefore could be more deliberate in our approach to the improvement opportunity planning and implementation.

Don’t forget to leave your comments below.

Re-engineering your way to a Project Management Office

Written by Tom Flynn on September 2, 2014. Posted in Articles. 5 Comments on Re-engineering your way to a Project Management Office

The emergence of the project office is being driven by the desire to improve and standardize the success rate of Business and IT projects that continue to increase in breadth and complexity. Another driver for the project office phenomenon is the need to relieve project managers of the administrative requirements associated with successfully managing projects.

In the past, a project office was defined as a structure to develop best practices as well as maintain focus on the project management discipline. It was generally recognized as a repository of project information controlled at the strategic level of an organization. Currently, the concept is being refined out of necessity and assumes more of an operational support role for the project manager. Within this context, the project office is more appropriately defined as an organizational mechanism that assists the project manager in consistently achieving project goals by providing assistance in planning, estimating, scheduling, contracting/procurement, monitoring and controlling the project. Organizations implementing this type of project office methodology are leading the way toward a model for world-class project management.

Project office functions can be virtual or staffed. Many forward-thinking organizations are blending the aforementioned strategies and utilizing the project office to support strategic, operational and tactical objectives. In addition, the project office staff is comprised of both dedicated and just-in-time personnel.

Functions of a Mature Project Office

A mature project office provides many types of services. Corporately, the project office is generally regarded as a Project Management Center of Excellence. The professionals who staff these project offices should be experienced and trained in advanced management and leadership skills, as they will continually collaborate with senior project personnel, senior management, and staff at customer decision-making levels. Ancillary resources either assigned to the project office or to a specific project must also behave in alignment with the norm.

Some of the services performed by project offices include specific needs training, best management practice (BMP) development, administration, consulting and mentoring. In large firms, it also provides a home base for project managers as we have described in earlier paragraphs.

Specific Needs Training

The project office should be concerned with training relevance and consistency. In addition to staffing fulfillment, the project office should provide a full range of specific needs training for project managers and project teams. This training should be delivered on a scheduled basis as well as through a request cycle for organizational needs outside of the PMO. In essence, this format will promote the PMO as a resource center.

Best Management Practice Development/Methods and Standards

Project management processes are developed, used, refined, and implemented throughout the organization as best management practices by the project office. For example, the project office should enforce a project management process that spans the project selection to project closure phases. From these processes, metrics are developed to measure project performance and improvement. These best practices and lessons learned are stored in a repository for use on subsequent projects, hence building accuracy, mitigating risk and reducing cycle time. The data is accessible and used by the core PMO team and any other resource working inside the PMO structure.

Currently, many mature project management organizations use their intranet and website as repositories for best management processes and practices. A mature project office should eventually utilize external benchmarking to further improve project performance and organizational efficiency.

Project Administration

In most organizations, project management means scheduling. In addition to scheduling, the project office should also be involved in project planning, resource estimating, contracting/procurement, project control, variance analysis and administrative support. The administrative support can be significant. Recent studies indicate that over 50% of the project manager’s time is devoted to administrative tasks.

Project Consulting & Mentoring

Many organizations are using internal consulting/mentoring to supplement and complement their formal project management training. The mentors/consultants can develop inseparable relationships with project managers if they provide value to the project. The reputation of a project office is built upon continued responsiveness to the project management needs of the organization.

This model works well in organizations that are utilizing a more virtual design. Project managers who are not necessarily working under the PMO, but who are working with the established methods may call upon the PMO to provide consultation. The relationship imbeds continuous learning and improvement into the organization’s corporate norms.

Project Managers

The project office is an ideal place to maintain a pool of project managers. Project managers may be assigned to the project office in order to monitor their career development, job assignments and job performance. Based on the project manager’s availability and experience, they are subsequently assigned projects of commensurate duration and complexity. Project managers that are in the pool can use down time for personal development by attending training courses or serving as mentors or peer review personnel. Understandably, resources in the pool will have other job responsibilities. Utilization of the pool concept will allow a project office to expand and contract with the project portfolio. In addition, it provides a dynamic model for performance management, allowing far better control over cross-functional performance. Human Resources will play a critical role in the build out of this model and should be integral in its development and implementation.

Client Considerations

The functions as listed above are a cross-sectional view of a mature PMO’s functionality. It is important that this overall functionality be considered prior to the development and implementation of a PMO. Unless the end-state model is planned first, the development of processes, tools, and methods will be interruptive. Experience shows that it is not a wise practice to develop and implement a project methodology and/or PMO without utilizing the practices that it espouses. The failure to lead by example has resulted in the collapse of many PMO efforts, leaving a bad taste in the mouths of the project resources.

The development of a project methodology and project management office is a sizable effort. When a simultaneous reorganization effort is factored in, the risk level is elevated and the probable success level of both efforts is lessened. This illustrates a compelling reason for both of these end-state models to be well defined at the outset.

In 95% of the PMO implementations we have been involved with, the organization undergoes a detailed assessment of the project management norms, culture and competencies of the project organization. In this case, the business clients would also be included in the assessment to ascertain the perceived level of service from the IT organization, identify critical interfaces and cross-functional work flow as well as obtain buy-in for the project management methodology. The IT organization is a service provider to business units; therefore, it must gain approval from, and seek collaboration with, the client for the methodology to be assimilated.

Project success is largely dependent upon the amount of detail extracted during front-end planning. For this reason, most methodology and PMO development efforts are phased in over time, driven by a detailed plan relative to the complexity of the methodology/structure, and results of an organizational assessment. In addition, the rate of change that is organizationally acceptable must be considered.

The assessment will also identify the areas at which milestones, quality control checkpoints, communication processes and other critical Business–IT interfaces should be designed into the methodology. Specific needs training will be based on the competency assessment results. The results can be utilized to create a human resource-based project management career track embracing the necessary training, experience and time on the job elements required. These elements will not be limited to the PMO. In support of our earlier recommendations, these norms and competencies should be made visible and accessible to the entire organization.

The utilization of an experienced PMO consulting organization that understands the strategic, operational and tactical interfaces of project management would ease the overloading of PMO resources and assist in the control and redirection of the cultural repercussions that are inherent in such a change-based effort.

Summary

Undertaking a parallel reorganization and PMO effort will understandably add to the complexity of work. However, it is our opinion that doing them in a vacuum will not render optimum results. If the IT organization is being reorganized to promote cross functionality, service provision and internal efficiency, a standard project methodology is a requirement.

A well-executed process and methodology implementation will allow Business and IT to come together prior to actual work beginning. The benefits of this union are as follows:

Business/IT expectations are clarified
Measurable processes are created for both the implementation of project work and continuous support
Performance measurement programs will be established allowing for cross functional consistency around reasonable expectations
Human Resources will become integral in resource availability and competency issues allowing for more focus on the project manager’s part
The project portfolio will be guided more directly by the organization’s strategic initiatives
Cost factors will be compared more accurately
Change will be managed more effectively

The aforementioned bullets are meant to be a macro look at the impact on the enterprise. Obviously, cultural norms, business environment and competency issues will need to be observed prior to formulating the assessment or stating recommendations.

Undertaking a project of this capacity can be overwhelming if not approached methodically. However, the end result as indicated above offers a variety of direct and ancillary benefits to the project management function and the entire organization.

Don’t forget to leave your comments below.

Recovering Distressed Projects

Written by Tom Flynn on August 5, 2014. Posted in Articles. 4 Comments on Recovering Distressed Projects

Defining Distress/Basic Life-Cycle

Over the past few years, assignments involving “distressed projects” have been far too frequent for the maturing state of corporate project management. Requests to “recover” a project that has strayed into the territory called “distressed” usually come complete with a panicked urgency to locate and solve issues including emotional distress, protectionism, and a myriad of other valid reasons for the current condition. Amidst the chaos and high-
emotion, the project must be assessed without prejudgment or bias, and lead to a path of recovery. This article will deal with a consulting life-cycle approach to uncovering issues that have contributed to the distressed condition and recovering as many of the project’s original objectives and expectations as possible. Distressed projects have no industry preference; they are equal opportunity employers. Therefore, the practices discussed here are
applicable to all industry types.

Defining Distress

In our consulting practice, we generally use the term “distressed” to represent a project or program that is 20%> off its cost and schedule baseline targets, exhibits missed milestones and has missed key deliverables. For the sake of recovering a project to its original scope expectations, the earlier the project is recognized as “sliding” the better. You may be asking, “Why only recover the scope expectations?” In many recovery efforts, our involvement begins well beyond the beginning phase of the “slide”. It is a foregone conclusion that the schedule and budget will need to be expanded to allow for original scope expectations to be met. In cases where schedule and budget cannot be expanded, scope is decreased to meet these constraints. PM stands for project management, not project magic! When a project has slipped into serious distress, recovering scope expectations in a stressful environment without major time and cost overruns is a feat in and of itself.

The Basic Life-Cycle

Although all distressed projects have unique issues, we have had success in using a basic and consistent life-cycle approach. The four-phase life cycle pictured below (truncated) has been developed over time and over many of these types of assignments. It is free of non-value added deliverables and is aimed at quickly and accurately getting to the heart of the distress, implementing the corrective action plan, executing and controlling new deliverable development, and executing formal project closure practices/processes.

Entering Phase

Someone once asked me why we call it “entering” and not “initiation”. My response was that the project already had an initiation phase. We are not initiating a project; we are entering a project that is in progress and has specific history associated with it. The term “entering” reminds us that we are not starting with a clean slate. To the contrary, we are in the middle of something failing that requires professionalism, patience, insight, tact and critical thinking in order to make a positive impact. Also, we are reminded that entering in the middle means we must exercise diligence to quickly get caught up on the underlying context of the project. This requires much listening and observation.

Scope Development

Whether we are consultants or internal resources, developing the consulting scope to recover a distressed project generally involves achieving clarity around and documenting the following areas:

Initial project expectations (history)
Current organizational assessment of the project
Expectations of the recovery assignment
Agreement on our approach (or variations) to the assignment

Schedule Initial Interviews and Data Gathering

In order to properly assess the project, we must interview a varied group of individuals who are directly and indirectly involved with the project. Generally (and hopefully), the individual responsible for our involvement with the project will have identified the organization’s key resources. At a minimum, the following resources should be interviewed:

Project Sponsor and/or Steering Committee Members
Project Customer
Project Manager and Staff (collectively and individually)
Key Functional Managers
Key Technical SME’s and/or Team Leads
Schedulers, Controls Resources, and PMO Resources (if applicable)
Key Project Team Resources (formal and informal leaders)

As mentioned earlier, each will have a story to tell about the original intent and why they feel the project has declined to its current status. One must be careful not to get hooked into the emotion of the situation. I recently entered into a very large program that was in a critical state. The emotions were highly charged, fingers being pointed in all directions and mistrust was on the rise as various functional groups took up their positions of defense. Experience teaches one to get past the emotion by calling them back to the real events, what happened (not why) versus their opinion of what happened.

Analysis and Assessment Phase

Also, when one gets caught up in the emotions of the project, it is easy, with no malice, to agree with folks about just how distressed the project is. As innocent as this may be, it should be avoided at all costs. One of the first cautions of “entering” into a distressed project that will assist us in being quickly accepted as a non-biased peer reviewer is being very careful not to disregard the entire project. Regardless of the current condition of the project, many people have worked very hard and generally have done what they thought to be the right thing. They have been surrounded by the project daily, which, after a while tends to limit one’s observations and insights. We come in fresh and our lack of specific history and emotion allows us to see things they may not. A good rule to use is not to make any observations or pronouncements (public or private) until you have thoroughly assessed the current situation. Project resources appreciate this type of professional restraint and are much easier to work with if they are not on the defensive.

Analysis and Assessment Phase Depending on the point of entry, i.e., the level of current distress, this phase can be the most labor intensive of the assignment and not a glamorous one either. This is where the picture of the project, past and present, comes together for us. One must have a great deal of tact, yet possess plenty of tenacity in order to get to the nexus of the distress without alienating everyone at the same time. We will need to maintain very professional relationships during this phase as we will need buy-in and validation for our proposed solution later on.

Conduct Initial Interviews – Data Gathering, Documentation and Data Review/Evaluation, and Probative Interviews

Although distinct, the three processes above share enough commonality for us to discuss them together in this format. Many of the initial interviews will give us access to the project’s required documentation/data. In some instances, the data may be presented to us prior to the interviews. I prefer the latter. Having an opportunity to examine project documentation/data helps me form pointed questions for the interviews. This helps keep the participants focused on what happened, out of the emotional realm. From the consultant’s point of view it helps to keep the interviews from becoming a blur of repetitive conversations.

Once the first round of interviews and documentation/data review has been executed, we will conduct probative interviews that will be used to “drill” into specific areas uncovered earlier. Projects create a great deal of documentation and we can get overwhelmed if we allow the client to make a doc/data dump. To begin with, we will review the following specific documentation:

Charter and Project Approval Documentation

Project Charter (Initiation Mechanism)
Scope Statements (preliminary and definitive), Scope Development

Documents, Reviews, and when Scope was “frozen”

Baseline Development Documentation
- Project Estimates including basis of estimate documentation (ROM, Conceptual and Definitive; consistent with project size and complexity)
- Project Schedules (with resource loading)
- Project Design Basis Documentation, Reviews, and when

Design Basis was “frozen”

Project Execution Plan Elements including (at a minimum)
- Communication Management Strategy
- Scope – Change Management Strategy
- Risk Management Strategy
- Procurement-Vendor Management Strategy
- Project Controls Management Strategy
Integration – Handover – Closeout Management Strategy

Many times, these documents-artifacts have not been created. Or, they were created in order to gain project approval and have not been kept up to date; both are signs that project execution planning may not have been robust enough. Benchmark studies confirm that a lack of execution planning is a key cause in project distress and failure. This will be discussed later.

Developing Conclusions and Solution Approach

This area is where experience plays a predominant role. As previously mentioned, projects are unique in their specific characteristics, yet sources of distress usually align with benchmark findings and common empirical results from one distressed project to the next.

This certainly isn’t a rule yet; we do see many of the same “snags” from project to project.

Below are just a few of the common distress factors we have seen in the past few years:

Ineffective and untimely senior management decisions
Ineffective expectations transfer from client to provider (contract terms misunderstood)
Ineffective Stakeholder Communication
Lack of Execution Planning
Lack of Scope and Design Basis Freeze prior to final estimation or definitive contract terms
Project or Program is beyond the experience level of the

Project/Program Manager

Inadequate project structure and/or resources

Solutions are comprised of specific responses to causal factors and vary project to project based on culture, organization, resource levels, management buy-in, etc.

Gaining Approval and Consensus (findings and solutions)

Difficulty or ease in gaining approval, validation, and consensus is usually and directly related to the level at which the causal factors occur. Strategic or senior management level – difficult, Operation or Management level – easier, and Tactical or team resource level – much easier. Regardless of the level, the solution(s) must be presented in a logical, “threaded”, and no-blame manner in order to gain approval and consensus across the necessary constituencies.

Execution and Control Phase

Of the four required phases involved in recovering the distressed project, the Execution and Control phase signals a temporary sigh of relief. Although much more work will be required, it signals that we have properly assessed the issues with the prior project difficulties and our solution has been validated and approved.

Execution Planning

During the Analysis and Assessment Phase a fair amount of execution planning would have been committed to in order to develop sound and approvable solutions. In this phase, we will complete the definitive execution planning for our solution. Over the years, we have seen that most distressed projects lack proper execution planning and where there is a lack of execution planning; there is a lack of execution cognizance and the lack of proper resources for execution and closeout. Elements of a sound project execution plan (or project plan) include the elements-areas listed below and will vary from industry to industry.

Project Management	Design Management	Security Management
Risk Management	Information Management	Controls (Scope, Time, & Cost)
Communications Management	Resource Management	Quality – Testing – Validation
Quality Management	Procurement Management	Implementation – Closeout

With the proper execution elements addressed, planned for, and documented it should be very clear which resources we will need to execute our overall recovery plans.

Roles and Responsibility Determination

With a solid execution plan in place and the team resources identified, alignment sessions are utilized to review all deliverables, major roles, support roles, interdependencies and the required timing for deliverable development. Regardless of the size of the project effort, roles and responsibilities should be clearly documented using a basic RASCI (Responsible, Accountable, Support, Consult, & Inform) tool. For more definitive detail a complete WBS Dictionary may also be utilized.

Schedule and Budget Development

As with execution planning, we would have determined initial schedule and budget implications during the development of our recovery solution. In this phase, we will be developing the definitive master schedule and associated budget baseline (supported by our definitive execution plan). In sizeable project efforts is advisable to utilize a dedicated scheduling resource (master scheduler) to develop and administer the project schedule. Many best-in-class organizations have realized that expecting the project manager to develop and maintain a complex network schedule and manage the various constituencies on the project is a tall order to say the least. Scheduling is a professional discipline and project scheduling on large and complex projects borders on being an art form. Developing accurate baselines that can be monitored, trended, and controlled is well worth the additional cost of the scheduling resource and in a recovery effort, we can’t afford to miss the target a second time.

Project Control Strategies in Place

Developing sound project control strategies begins with accurate and “controllable” baselines. As mentioned above, a dedicated scheduling resource can make this “control” possible for the project manager. Experience has clearly shown us that for any sizeable effort, the project manager will not be able to successfully perform both the management and control duties required by such a project. In addition to accurate baseline development, sound project control requires the development of the following elements:

Key milestones identified and attributed with deliverables
Key deliverables with clear completion metrics
Formal execution reviews (performance and risk related)
Earned Value and Burn Rate strategies (monitoring and trending analysis)
Defined and consistent performance reporting requirements for team members

Deliverable Execution and Validation

Once controls strategies are in place deliverable execution may begin again. Our control strategies and practices will assist in trending actual performance against our baselines and incrementally validating deliverable execution (and reacting to variance).

Closing Phase

For most projects, especially those that are large and complex, project closing is accomplished in a phased manner, or “rolling-wave” closing. It is not inconceivable to have early deliverables or portions of the project in implementation/Operation while we are still completing later deliverables. The “fast track” expectations of most projects will ensure such a phased closing schema and adds another layer of chaos to the project. Also, and as true for many projects, organizations begin to “strip” resources from projects as they appear to be reaching the finish line. The project manager will want to guard against this by modeling (in the risk assessment) the adverse effects of prematurely diverting key resources to other projects.

Solidify the Transfer, Handoff, and Implementation Plans

This element of the overall project execution plan (project plan) requires a great deal of time and coordination to develop and solidify. Customer and project resources must be in alignment on roles and responsibilities for:

Final testing and validation
Training (content, materials and facilitation)
Implementation assistance
Timing for “custody” handoff of phased deliverables (project-based to operations-based transfer) the “roll-over”; the graphic below illustrates what we refer to as the “rollover”, i.e. the Project Manager rolling down to the support role and the Customer rolling up to the leading role.

Execute Phased Implementation and Signoffs

If the Transfer, Handoff, and Implementation Plans are complete than the phased implementation and required signoffs can be executed as scheduled. For projects where the closeout phase is highly complicated, a separate and more detailed completion schedule (inch-stone schedule) may be needed to ensure a successfully executed closeout.

Final Audits and Lessons Learned

In a phased closeout the final audits and final lessons learned sessions will coincide with the phased execution schedule. It seems that no matter the size and criticality of the recovered project, there are always plenty of reasons to avoid the audits and lessons learned sessions.

These practices are important for any project and organization and in the case of a recovered project where we will have spent significant sums of time, money, and attention to rein it in; we should commit to their execution in order to memorialize the initial issues and their costly solutions.

In summary, with a detailed and methodical approach to recovering projects, the effort need not be cathartic yet, it is still a wiser and less stressful approach to commit to the proper planning and diligence initially.

Don’t forget to leave your comments below.