Skip to main content

Author: Mike Lecky

Answering Some Standardized Questions

Written by Mike Lecky on . Posted in Articles. 7 Comments on Answering Some Standardized Questions

Why refer to a standard for project management?

How can a standard for project management deliver value?
When it comes to technology we can all appreciate the benefit having standards. We plug many different devices into the electrical power receptacle and they all work. We listen to songs and podcasts from hundreds of publishers in MP3 format on our iPod. We can print from essentially any computer to any printer provided we’ve installed the correct printer driver to establish the interface.

Standardized technology enables interchangeability and facilitates international exchange of goods and services. It removes barriers to trade and promotes transfer of technology. It has the effect of reducing variety leading to increased economies of scale.

Standardization has the effect of increasing the availability of products and increasing the interchangeability of products that must perform together. Functional characteristics and methods of testing become widely understood spawning improvement and innovation.

The BSI Group, founded as the British Standards Committee in 1901, states it nicely:
“Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use.”

It’s really an easy stretch of the imagination to envision all these benefits of standardization applying to the processes and technology of project management. And when we consider the spin BSI puts on it, who wouldn’t strive for standardization in every aspect of their project management program.

Monitoring Many Small Projects

Written by Mike Lecky on . Posted in Articles. 5 Comments on Monitoring Many Small Projects

Steering committees tend to focus on large, high profile projects. Yet senior managers have a responsibility to ensure that all projects align with corporate direction and that the benefits projects promise are indeed realized.

The concern is that in most organizations there are usually many smaller projects that consume a significant portion of the overall project budget.
This means senior management must monitor progress of smaller projects as well and act accordingly in response to issues and risks.

A steering or oversight committee is one means of achieving this. These are usually reserved for larger initiatives or a collection of projects belonging to the same program but can be very effective in monitoring all projects in a portfolio.

So the question becomes:

In organizations with a hundred projects, and there are many of these, how can monitoring best be achieved?

In these situations, monitoring controls by senior management are usually achieved through a reporting structure. Reports from individual projects are aggregated into summary reports which are presented and tabled for discussion during period oversight review meetings.

These summary reports or ‘dashboards’ vary considerably from one organization to the next. Generally they all include some basic metrics such as the number of projects in each phase, the status by project (i.e. red, amber, green), cost to date/variance and estimate to complete by project, project scope changes and key issues.

Depending on the maturity of the project practices, these reports might include trend indicators giving management visibility on other key controls over projects. These might include a running measure of the number of projects that hit (or missed) key milestones. Items like risks and the status of risk indicators, schedule variance and resource trending by project tend to be more involved. Increasingly, managers are seeing the value of monitoring these items in the context of the project portfolio.

The key controls to watch for over a project’s life might include attaining approvals for project funding, project closure or for key project documentation such as business case, scope, verification strategy, user acceptance test results and deployment plan. Other controls take the form of reviews and decision gates and give rise to decisions to proceed with the project, to advance the product of the project into production or to deliver to customers.

Of course there are many considerations in managing and monitoring a large project portfolio budget. Having a means to assemble and review relevant, consistent and accurate information on active projects should be a first priority for good project governance.

Where Risk Management Trumps Quality Principles

Written by Mike Lecky on . Posted in Articles. 2 Comments on Where Risk Management Trumps Quality Principles

For those of you who haven’t already completely forgotten about the Maple Leaf Foods tainted meat disaster, there is a lesson to be taken away about managing risk.
I find it incredibly interesting that the policy followed regarding testing of meat was to test swabs from the machines. If these were okay then the meat could be shipped. Even more amazing is that, if a machine test swab failed, all that had to be done, by way of accepted industry best practice, was to keep cleaning and retesting the machine until a pass was achieved. The meat wasn’t tested.
It seems like the traditional quality principle failed us this time. That is the principle that says control the process (in this case the process machinery) and you’ll be successful controlling the outcome of the process.

While I can appreciate where some quality gurus might weigh in on this when it comes to processed food, as a consumer and meat-eater, I’d like to see testing done on the end product before it gets to my table.

So what’s to take away from Maple Leaf Foods for project managers?

Let’s start with the definition of quality. There are several definitions but for the PMP exam it’s sufficient to know that quality is ‘every characteristic that influences satisfaction’. Not meaning to be glib I’d say that dying because of your salami sandwich would be most unsatisfying.

When you’re managing a project the quality plan describes how the quality policy will be implemented on the project. And this is where we need to be careful because, if the policy is poor, the project will be a failure.

If the business objective is at risk, for any reason, then as project managers we’re obliged to register the risk and address it. Escalate it if necessary. In the case of Maple Leaf Foods it seems the quality policy on this matter was insufficient to cover a business objective of providing safe-to-eat food.

If your project was to set up a process for making meat you’d want to identify the risk event of shipping bad meat. Clearly in this case sampling the output of the process would have mitigated the impact of the risk event. But this was not in line with the quality policy at Maple Leaf.

The take away for project managers is that, if there is a risk that business objectives will not be met, then those risks must be fully explored, regardless of company policies.

Risk management in projects is not limited to identifying project risks alone (i.e. risk events that may result in cost or schedule overruns). Risk identification should include risks the solution delivered by the project to the business will fail to meet the objectives. No pun intended.

Different Project Managers for Different Projects

Written by Mike Lecky on . Posted in Articles. 8 Comments on Different Project Managers for Different Projects

The skills of the project manager need to match the project and the people involved.

It’s an important issue since the success of a project is dependent on the competency of the project manager. Every project is different and this presents a challenge.
So how do we minimize the risk of an inappropriate project management assignment?

One approach to treating this risk is to first build an understanding of the project environment, the work involved, the people participating and, last but not least, the customers’ expectations. Then use this understanding to assess the importance of some basic competencies common to most project managers. Your understanding of the environment, work and people will point you to the specific qualities – and to any unique competencies – key to the success of the project.

There are several sources that can be used to frame the ‘basic competencies common to most project managers’. The PMBOK suggests project managers should have domain knowledge in the application area of the project, general management skills, soft skills related to people management, project environment knowledge and understanding and experience in the nine management knowledge areas.

Another view is provided by Jennifer Krahn (from recent PMI Research Conference Proceedings Effective Project Leadership: A Combination of Project Manager Skills and Competencies in Context). From her work, the ten most important skills and competencies for project managers are: people skills, leadership, listening, integrity, trustworthy, verbal communications, team building, conflict resolution, critical thinking and priority balancing.

Yet another alternative is provided by William Lei and Martin Skitmore (from Project Manager Competencies: A Survey of Perspectives from Project Managers in South East Queensland). Lei and Skitmore frame abilities along slightly different lines: meeting project deliverables, making decisions, controlling costs, leading project teams, organization, planning, conflict resolution, problem solving, motivating, meeting project quality objectives, negotiating, delegating tasks, team building and managing legal issues.

To these lists I’d add visioning skills and the ability to manage expectations and conduct effective meetings. Clearly there is no comprehensive, ‘one-size-fits-all’ list for all situations.

When selecting the desired project manager competencies, you identify the characteristics of the project environment, project work and people involved. As an example for a large project high importance might be placed on finding someone with significant relevant prior experience and good team building skills. On the other hand a project with lots of uncertainty may place more importance on critical thinking, risk management and people skills.

We know that projects fail for numerous reasons. Selecting the ‘right’ project manager means selecting the project manager with the ‘right’ competencies. This is one way to reduce the likeliness of failure due to ineffective project management.

Managing Requirements Gathering

Written by Mike Lecky on . Posted in Articles. 4 Comments on Managing Requirements Gathering

A structured approach to requirements gathering during the early stages of a project can pay large dividends later.

Have you ever entered into a project as the manager and been expected to follow a previously established process or project methodology? Has there also been an expectation to meet certain milestones within certain dates, regardless of the scope of the project? Do you find there are great pressures to rush planning and requirements definition activities?
I’m sure you can relate to these questions. And to deal with these time pressures there are a few techniques you can build into your project early to help gather requirements quickly.

A growing number of organizations have developed project management frameworks in order to achieve a degree of structure. These processes can be viewed as management controls over projects. They are intended to not only standardize activities in the organization but also add visibility to the project progress, support decision making and streamline the work to ensure success.

These frameworks may be large and broad such as those laid down in SDLC (Systems Development Life Cycle) policies. These would apply generally across large corporations and often highlight management decision points in the process. Other frameworks are more detailed and fitting to the mandate of departments they support. Many smaller organizations are highly focused on a certain types of project deliverables and their processes are tuned for this.

In any case, all these frameworks are only as good as the definition of requirements for the projects that must follow them.

We all know that if the project deliverables and the criteria for success are not clearly defined then the chances of meeting scope, schedule and budget objectives are limited.
And yet I find that many of these staged processes come with management expectations to rapidly move through early stages.

Depending on your project situation there are three techniques you might consider to gather requirements information.

First, you can build a series of formal interviews with key individuals into your project plan. This is by far the most common approach. The best results are achieved by keeping the sessions formal and making sure the interviewees have the authority to make decisions on requirements. It is important to very clearly articulate the objectives of the interviews and follow a pre-prepared agenda, which should be sent out ahead of the interview.

The second approach is to use surveys. This might work well in situations where a large number of people need to be consulted or if the individuals are geographically dispersed. It can often be difficult to arrange a good time to meet with a group of people who are in different time zones. Keep the survey questions short and to the point. A survey with 10 questions delivered in a web-based format is likely to yield the best response rate.

Finally, you can conduct a facilitated requirements gathering session. As with the interviews, be sure the attendees have the authority to make decisions on requirements. A successful facilitated session requires planning. As a facilitator, you’ll need to consider a neutral meeting location, the session duration, how consensus will be achieved and the agenda, which may include an icebreaker. In some cases a short training period is helpful to level set attendees.

All these techniques should be followed up with a summary of the information gathering activity (i.e. minutes or survey results) and a list of follow-up activities for completeness.

Regardless of what project methodology you are expected to follow, if you get sponsor buy-in to a formal requirements gathering phase and use these activities early in your project, you’ll be sure to firm the requirements and get more issues on the table sooner. Later during project execution you’ll be much better positioned to monitor and control the project and manage the various scope changes that may arise.