Skip to main content

Author: Mike Lecky

Addressing Common Problems with Projects

A recent failure of a 60$M telecom project invites the question of why?  The answer:  poor leadership.

But this answer is too general.  It doesn’t really help us understand what we can do as project leaders to increase the likelihood our projects are successful.

If we consider problems found to be common to projects we might find ways to proactively address those problems before trouble begins to surface: 

  • The project objectives and scope are unclear
  • Estimates for time and cost goals are unreliable or unrealistic
  • Changing business needs or technology impact the project
  • People working on the project are incompetent or unmotivated
  • There are poor conflict-management procedures
  • Communications are poor
  • Suppliers are not delivering as promised
  • The project sponsor or senior managers are not very supportive of the project
  • The project manager is inexperienced in managing people, working in a particular organization, or understanding the application area of the project
  • Key stakeholders, such as customers who would use the product of the project  and services the project is attempting to create, are not sufficiently involved in project decision-making

To address these it’s helpful to group them into actionable areas that apply to you and your project.

In doing this let’s keep in mind there is a high correlation between project success and project manager competency.  I know, it seems an obvious statement but it is important to distinguish between a project manager’s strengths and the challenges presented by the environment of the project he or she is managing. 

First, consider your project environment and identify what is in and what is out of your direct control as a project manager.  Just because something is out of your direct line of control doesn’t mean you are not responsible for it.  You’ll still be able to influence it.  You’ll need to be creative and draw on your support network to affect outcomes in these areas.

Second, your competencies as a project manager can be viewed in terms of technical abilities (e.g. scheduling, estimating, earned value analysis) and management strengths (e.g. visioning, facilitation, motivation).  Looking at how your hard and soft skills might contribute to these problems is a first step to identifying what you might do about it.

This analysis might help you hire a project coordinator with the right technical skills to complement your own.  If the organizational structure keeps you at arm’s length from vendors you might engage your procurement organization to establish specific supplier controls early on.  You can then influence vendor outcomes indirectly in an oversight capacity and by monitoring progress.

Of course good practice is to do a lessons learned on failed projects.  The problem with this is it’s too late.  The project has already failed.  There’s a need to be proactive and take action early, perhaps before the project starts, to mitigate the risks of project failure.

As a final note, it’s coming up to nearly two years now that I’ve been writing this Project Times blog.  This will be my last for now.  I continue to participate on the ISO committee to develop the new international Project Management standard, ISO 21500 and to teach project management on a part time basis at Humber College.  You can reach me at [email protected] and I’d welcome the opportunity to discuss any project issue you may have.

Security Considerations for Managing Project Information

How do we achieve balance between ensuring that project information flows freely and protecting sensitive information?
As project managers, one of our primary roles is to make sure information flows between those that need it to do their job and support the project. But we’re also responsible for ensuring that corporate information assets and strategic information about the project remain secure.

The 2005 edition of ISO 17799 (Code of Practice for Information Security Techniques) advocates a risk based approach to managing sensitive information. This applies equally to information flows in projects.

It’s well understood that achieving increased security usually occurs at the expense of the user and, in this case, project stakeholder expense. For example, certain files we may want to view may be subject to restricted access. It’s an extra step which serves to limit the exposure of information to those granted the privilege of access. Access may require an additional password or other authentication technique, adding yet more difficulty to the process of restricting the information on an ongoing basis.

So what do we need to consider when deciding how to protect sensitive information? We don’t wish to overburden project participants with access limitations, nor reduce efficiency in our project execution? We need a balance.

First, identify sensitive information and rank the risk of exposure. This will guide the level of effort you apply to restricting access to key project stakeholders. “Need-to-know” is the guiding principle here.

Second, you can review your project activities and resource allocations in terms of “separation of duties.” The idea here is to limit an individual’s ability to act irresponsibly (intentionally or accidentally) based on the information they have access to. Of course, clear lines of separation and an understanding of what individuals need to know is necessary for this to be effective. Segregating roles reduces the risk of collusion as well as protecting corporate assets.

Finally, “cross-training” can be used to increase the likelihood that the people with the right knowledge will be available to perform project activities at the right time. It ensures an alternative when individuals who have developed specific knowledge based on their access to privileged information become unavailable to support the project. The availability of key people should play into your assessment of risks regarding sensitive information.

By considering these three security principles, the appropriate level of protection can be applied to project plans based on the risk of exposure of the information assets. Plans can mitigate or avoid risks of exposing sensitive information and project delays due to the unavailability of key stakeholders.

The Jewel of Investments; Increasing PM Maturity

In times when the economy is in a tailspin the case to increase the maturity level of project management processes becomes stronger.

The benefits of more mature PM processes include reduction in costs and an opportunity to stay competitive. Project life cycles are reduced and quality of deliverables increased. Resources are better allocated and project investments are more closely aligned to strategy. Increased maturity translates to a better customer experience.

Fortunately there is much work done on increasing maturity of project processes and this should be leveraged when taking on the challenge to better project management in your organization.

A primary up front study is to review the various maturity models available. One of these is provided in the Control Objectives for Information and Related Technology (COBIT) standard. This is a framework of best practices published by the IT Governance Institute.

There are six generic levels of process maturity defined in the COBIT:

  • Level 0 is characterized by a complete lack of process or acknowledgement that it is needed.
  • In level 1 there is recognition of the need for standardization, however ad hoc practices are applied on a case by case basis at the discretion of individuals.
  • In level 2 similar processes are followed by several people doing the same task, however there is a high reliance on the expertise of individuals and no or little training takes place.
  • In level 3 standards begin to emerge as practices are formalized to procedures. These are communicated and followed with deviations which are unlikely to be detected or managed.
  • In level 4 processes are managed, measured and subject to constant improvement.
  • Level 5 fully incorporates best practices into the working fabric of the organization through automated execution processes and established processes to improve effectiveness and quality.

Levels 1 through 5 are commonly labeled Ad hoc, Defined, Controlled, Measured and Optimized in other publications and standards for capability maturity models.

According to recent research published by Info Tech Research Group more than half of organizations are at level 2.

Interestingly the Info Tech research ‘peels the onion’ on maturity giving measures of contribution to maturity in terms of people, process and technology. They conclude that people maturity plays the smallest role yet it is a prerequisite to improving process and technology practices.

Another perspective on improving maturity is given in a recent article in the PM Network magazine. In the article entitled ‘Minding the Gap’ Peter Fretty quotes John Schlichter who suggests going beyond methodology and process to governance when improving project management maturity:

“There is a difference between creating a standard and achieving standardization. The former is a document, whereas the latter is the result of effective governance, policies that distinguish what is important, training in which users experience their competence and a compliance function”.

The job of increasing project management maturity is not trivial. It’s fueled by solid oversight by senior management, an open culture, good planning and consistent, ongoing effort. Developing an understanding of current maturity is a good starting point to identifying what the best next steps should be.

It does take time to improve project management performance and improvement programs can yield near-term benefits when designed to do so. Organizations wishing to leverage the current economic climate are well advised to be lured to this jewel of investments and start acting relentlessly to increase maturity. They stand to gain a never-ending stream of lower project costs and better competitive positioning.

Project Managers and Downsizing

What should a PM do when the economy turns down and their employer must lay off workers? Large layoffs change the tone of the working environment and the resources available to the project. It’s also a pretty good indication the strategy of the organization has changed.
Recently Microsoft announced they would layoff 5,000 workers. On the same day Sony announced their layoff would affect 8,000. Clearly many of these workers would hold operations or manufacturing positions. We can only speculate how many would be supporting the myriad of ongoing projects in these two organizations. We don’t know how many projects would be affected by the changes although we can expect there would be many.

During the planning stages of large downsizing initiatives, senior management is tasked with assessing the impact of the cuts to active projects, and to projects in the pipeline for future initiation. The PM is not usually asked for the impact on their project prior to the layoff. That is, not unless the project is quite large or has significant implications to the competitive position of the company. Yet there is likely to be an impact and the PM has a responsibility to assess the impact and communicate their findings to senior management.

As a general guide the PM might consider three areas: alignment to strategy, impact on resources and affect on motivation.

In the face of tough economic times, organizational goals and the strategy to achieve these may shift. This would be cause to review the importance of all projects in terms of the value they are expected to deliver and their alignment with the new goals and objectives of the organization. A PM needs to be clear on the value expected from the investment in the project they are responsible for. If this changes so will the project scope.

Resources available to the project include budget for both internal and external spending. Changes in staff and contractors assigned may impact the project scope. Perhaps contributors with unique experience are lost impacting the ability to achieve the product of the project or to do so in previously established timeframes. Given the extent of the economic fallout, there is a good chance that changes at key suppliers will impact the project.

Finally, a significant disruption such as a large layoff can affect the remaining workforce by altering the tone and motivational dynamic of the working environment. Understanding the impact this will have on project activities is important to managing the project through the organizational change.

Whether project managers are asked for an assessment of the impact of a major layoff or not, it is incumbent on them to do so and ensure adjustments in the corporation are properly reflected in the project they are managing.

Measuring up

It seems that there are a few things that we just can’t avoid. Measures of what we do are one of them. And with the year coming to a close, there is often reflection on ‘how we’re doing’.

Project management and related processes are no exception to this. I’ve been recently involved in an effort to develop a release management process that dovetails into a project management framework and application development life cycle process. As you might expect, a few questions come up on metrics:

  • What should we measure in the process?
  • How should we go about it?
  • What should we focus on first?

When looking at measures of any new process, my preference is to keep the number of items measured to a minimum. It’s important they are easy to capture and, indeed, reflect what you are actually trying to monitor.

Some may differ with my view on this and suggest measuring everything. They’ll argue this approach gives a better picture and provides more data for analysis of the process. I say its better to observe the process and talk to the people involved to uncover issues and potential improvement areas. Additional measures can always be added based on this ground work.

In determining what should be measured, it’s useful to consider four groups of measures: scope and scale, effectiveness, efficiency and sustainability. For each group I start with a basic question. If we were looking at an organization’s project management processes, these are the questions one might consider important:

  • Scope and scale: How many projects and what types of projects are we supporting?
  • Effectiveness: How effectively were projects in meeting their objectives?
  • Efficiency: How well were the activities conducted during the projects?
  • Sustainability: What has been done to ensure the project management processes remain a ‘value add’ to the organization?

From here you can build a series of metrics each question and grouping. So for effectiveness, we might measure the number of projects we completed on time; simple and easy to measure. Such simple measures provide powerful views when consistently collected over a period of time.

Weekly reporting within working groups of the process is usually a good starting point for frequency of reporting. Monthly summary reports issued to oversight committees are also a good best practice.

For new processes the focus might be on measure of scale and scope and effectiveness. As the process matures, a shift to more measures of efficiency and sustainability can serve to highlight process improvement opportunities and to justify changes.

Like death and taxes we can only avoid being measured for so long. Unlike these other certainties why not embrace a metrics program if for nothing other than to record and celebrate how well we’re actually doing?