Author: Mike Lecky

Why Do Organizations Struggle with Project Management?

Written by Mike Lecky on May 15, 2008. Posted in Articles. 4 Comments on Why Do Organizations Struggle with Project Management?

There’s no one answer. Barriers to achieving project management maturity are as numerous as there are differences in cultures, business processes, corporate directions, technology infrastructures and skill sets. One certainty is that increasing maturity in project management increases overall performance.

Time and again presenters and researchers provide information showing remarkable increases in performance as firms move from one up to five on the five-point Capability Maturity Model (CMM) scale. It’s not at all unreasonable to expect an overall performance improvement in the range of 40%-70% in moving from level two to four on the model scale. This can represent a huge savings over the course of the three years it would likely take to make this climb.

Overall performance can be measured on several scales, depending on your organization. Ideally, it is aligned with the strategic initiatives and might be based on a scorecard approach. A scorecard model identifies and allocates key goals to different areas of the organization, providing performance targets which are then tracked over the course of a reporting period. If you were interested in setting a scorecard for project management, you might include goals to reduce project life cycles, decrease project cost, reduce unplanned work or reworks, and improved portfolio management.

Regardless of measurement approach, the key benefits of increased maturity are lower costs and shorter project cycles. Perhaps one of the more significant barriers to improvement is the difficulty companies have realizing tangible benefits when at early stages of maturity. The business case is tougher to make early in the climb. It’s a bit of a Catch-22: organizations with lower levels of maturity have limited competencies when it comes to measurement and self-assessment, while those higher in maturity have the rating because of their process measurement and analysis capabilities.

Achieving improvements in project management is not the work of a ‘lone ranger’. It takes planning, commitment and participation at all levels of management. Without long-term commitment from senior management, supported by visible short term ‘wins’ to sustain interest, even the most tenacious ‘agent of change’ won’t be successful. Knowledge of the improvement process and a clear understanding of what to expect in terms of performance improvements over time, is essential to build a successful maturity improvement strategy.

Those early in the climb to maturity experience greater difficulty, since roles, frameworks and formal definitions of process activities are less established. The foundation doesn’t start to solidify until repeatable process activities emerge in level two of the CMM. This makes getting a foothold on improvement difficult. As an organization continues its ascent to level three, controls over the repeatable processes are implemented. These take the form of reviews, metrics and escalations. And these, too, continually improve with the cycles of learning apparent from the increased visibility provided by measures on the process. Once refined enough by these controls, level four is achieved and quantitative goals can reasonably be set and met.

Most organizations wouldn’t see the need to invest in the process optimization necessary to achieve maturity beyond level four. Most certainly haven’t needed to consider this at all, since they continue to struggle with how to measure, analyze and action improvement of their project management processes. Perhaps this is a competency they should consider developing at the same time as they develop and train their project managers.

What Does Your PMO Do?

Written by Mike Lecky on April 14, 2008. Posted in Articles. 4 Comments on What Does Your PMO Do?

It’s a good idea for anyone wishing to improve their organization’s project capabilities to take stock of the PMO functions they already have. Several models for PMOs exist to help you better understand the needs of your organization and how building certain capabilities and competencies in your project office can help. There are as many PMO models as there are PMOs, so developing a specific understanding of what functions your PMO must have to best support the business is important to be successful.

One model I used to like compares various project management offices with familiar functions. For example, the project office can be viewed as a weather reporting office, reporting status information and giving insight into the health of projects. Or as a lighthouse, providing assistance to projects in the form of guidance, processes and best practices as they pass through their life cycle.

While the pictures conjured up by these comparisons are illustrative, I find they don’t hit the nail on the head when it comes to broaching the PMO as a key organizational and structural element intended to support the business. Increasingly companies, especially larger ones, are attempting to develop PMOs which integrate project and business processes.

We see this with the trend in recent years toward ‘Enterprise’ or ‘Corporate’ project management offices. These aim to address integration issues associated with the functional silos of the large organizations, or to align projects to business strategy, or to provide visibility on project spending and achieved value through various reports and dashboards. Many provide support publishing policies, procedures and guidelines. Others manage the project life cycle and integrate this to the system development life cycle, or to other key business processes linked to change and change management. Yet others fashion themselves as the center of excellence and central point of contact for the business. Still others focus only on staffing PMs or on financial reporting or vendor management.

Some try to do it all! But realistically can a single PMO do it all?

Well not unless it’s very mature. Not unless the business it supports needs it to.

Recently I’ve come across another model. It’s presented in a book titled The Complete Project Management Office Handbook, by Gerard Hill. The model in the book presents a comprehensive look at the project management office competency continuum. It presents the PMO and related functions and concepts with a pro-business slant. The book details over 20 functions and functional areas, which collectively comprise the competencies an organization may choose to support in their PMO.

What I like about Gerard Hill’s competency continuum is that it reminds us, first, that alignment of project activities to the business objectives is essential to ensuring that projects deliver value. Second, that to be successful a PMO must do a good job at whatever set of functions it performs to support the organization. And finally, these functions must help assure projects deliver that value which is required for the business to meet its objectives.

Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]

Breaking Down the Functional Silos

Written by Mike Lecky on March 18, 2008. Posted in Articles. 5 Comments on Breaking Down the Functional Silos

Project managers can leverage several integration tools to make their work easier and complete projects with greater assurance that they will achieve the expected benefits.

What are these integration tools?

They come in several forms and extend beyond the project-centric processes outlined in the integration knowledge area of the PMBoK. Examples of organization-centric integration tools are SDLC and change management processes, and enterprise risk and project portfolio management programs.

These activities are management controls that cross functional boundaries. When management supports these controls they become very effective tools to ensure the right projects get the right resources at the right time.

Traditional functional groups are effectively silos and are limited by the budgeting process. Allocation of resources to projects often suffers due to political agendas or to ‘the squeaky wheel gets the grease’ syndrome.

Project managers struggle in these environments to properly resource their projects with the people they need. Strong project-based matrix organizations experience less tension between the functional structure, which tend to be vertical in nature, and the more horizontally focused projects. Nevertheless, these still experience some inefficiency in project execution due to conflicting priorities of functional and project managers.

So how do these organization-centric integration tools help?

Perhaps the more significant contribution is the increased transparency across the organization that these processes and programs bring. For example, a management review of the project portfolio dashboard is certain to prompt action, if a key project is noted consistently to be under resourced and behind schedule.

Similarly SDLC processes are well-understood, staged frameworks for cross-functional development teams to follow. Functional managers and the individuals in these teams become accountable for deliverables within these processes largely because they understand their role.

The same is true for the change management process which governs what, how and when changes to business processes will be conducted. In both cases clearly defined controls in the form of events such as change board meetings require multi-functional representation. Because of these integrating processes, the priorities of the functional groups transitions from department-specific, internal goals to supporting cross-functional project initiatives.

Recently, I’ve noted more than a few organizations that have taken an additional step to facilitate integration and increase the efficiency and effectiveness of their projects and programs. They’ve altered the organization structure to align developers to the more horizontally oriented project teams rather than to the hierarchical functional groups. The change is aimed at improving resource allocation and has the effect of transitioning an existing matrix organization to a more project-oriented and less functional operating framework.

This sort of change has been shown to reduce overhead costs and contention between functional and project managers. I like it because it goes another step towards making the project manager’s job easier by helping them leverage organization-centric tools even more.

Portfolio Management or Just Resource Management

Written by Mike Lecky on February 19, 2008. Posted in Articles. 5 Comments on Portfolio Management or Just Resource Management

If you’re looking at improving your project portfolio efficiency and effectiveness be clear on what you need to focus on.

I experienced a situation recently where the motivation for project portfolio management was limited human resources. True, resource management is integral to portfolio management but broaching a limited resources problem with a portfolio management solution is overkill.

There are two things that project portfolio management aims at: alignment and contribution. ‘Alignment’ refers to aligning strategic objectives to investments, to projects and ultimately to resources. ‘Contribution’ means ensuring the benefits of the project as outlined in the business case are realized.

Resource management, on the other hand, involves putting the right type and amount of resources where they need to be, for the right amount of time. It assumes that decisions around what projects to do, over what periods, have already been made.

There’s a big difference between the two management activities. The most striking of these is the scope.

Portfolio management involves linkages between business strategy and execution. This requires a very different skill set than what you’d expect from a resource manager. It also requires continuous monitoring of project performance and risk indicators in order that the investment is protected.

Resource management is limited to resources not business decisions and not project health reporting.

If business decisions have been made to proceed with several projects, and there are insufficient resources to execute these projects in the time frames expected, then there is disconnect between the strategy and execution arms of the business. Either the total budget is not sufficient to support the aggregate cost (in terms of resources) of the projects, or the business cases have understated the amount of resources required. This is a problem portfolio management can resolve because it ensures projects are selected and prioritized based on total budget and resources available. Resource management will tell you to hire more people.

Today many organizations are faced with having to achieve more with less. There is always a strain on the resource pool in getting all work done. Targeting the problem of resource management by broaching assignment and allocation with a defined process, a skills inventory and a focused mandate can increase the efficiency and effectiveness of the overall project portfolio. It may not solve the problem of pushing too much work into the pipeline, but it will highlight disconnects between a strategic decision to proceed with projects and the ability to execute on these decisions.

It’s a great first step to introducing or improving portfolio management.

Creativity Cannot Be Scheduled!

Written by Mike Lecky on January 14, 2008. Posted in Articles. 4 Comments on Creativity Cannot Be Scheduled!

And more often than not problems take longer to solve than you’d expect.

The sort of problems I’m speaking of is often seen in projects where new technology is commercialized or where the availability of a new service depends on the introduction of new technology. It’s the type of problem where an obstacle presents itself and progress on the entire project is affected. Many times the barrier threatens a core feature the sponsor is eager to see.

So what can we as project managers do to deal with these very ‘hard to resolve’ problems that invariably arise?

There are several ways to address problems that arise over the course of a project. Each problem has its own attributes and requires its own approach to solving. But there are some generic actions you can take. These center around the notion that projects require a team-based approach to problem solving and a project manager can facilitate team performance.

The first and foremost consideration is that the team solving the problem needs to be a ‘team’. This means there has to have been something else they’ve done together prior to addressing the ‘big’ problem. I tend to look for things to nurture teamwork prior to taking on more challenging issues.

We’re all aware of the traditional phases of the team including forming, storming, norming and performing. We know the project team will drift in and out of these stages, depending on the dynamics of the environment and situation. If team members have a precedent on what to do to resolve smaller matters, then alignment of the team to focus on the more serious issue will be easier and faster.

Essentially we want to ensure team dynamics will not delay starting the problem-solving process. We do this by facilitating the team through as many ‘cycles of learning’ together as possible, early in the project. Here the cycles of learning apply to how members settle into their roles, share information and relate to each other in a synergistic manner. If they’ve experienced it before then revisiting it again for another issue is easier and hopefully progressive.

Another proactive approach is to mitigate the risk of technical issues through risk analysis and assessment. Unproven technology and integration issues can be difficult to uncover as part of the risk management process. However, the development methodology (i.e. agile, waterfall, prototypying, etc) selected for the project can help. For example, prototyping specific aspects of the technology or its integration can provide very illuminating results early in a project life cycle. Often these foreshadow where development ‘challenges’ can be expected. Schedules and budgets can be adjusted much earlier.

In closing, while good risk management is a great tool to identify potential problems, building a team ready and able to solve problems quickly and effectively is essential to deal with the uncertainty of scheduling solutions to problems.