Author: Mike Lecky

If Perceptions Are Everything

Written by Mike Lecky on December 14, 2007. Posted in Articles. 8 Comments on If Perceptions Are Everything

Mike Lecky’s Monthly Blog

When an artist paints a picture of a pond, we can look at it and see reflections of the shore on the water. If we can’t see the actual shore, then our only view of it is in the reflections. As a result, our perception of the shoreline may differ from what is actually there. A smooth, polished surface reflects true details, whereas rough waters prevent important detail from shining through.

I think you get where I’m going with this.

Recently I’ve done some work linking project risk management to information security risk assessments and enterprise risk management. An article in the November issue of PM Network magazine caught my attention. In her article entitled “It’s a Fine Line” Susan Ladika takes on the issue of how perceptions can affect project success.

One comment in the article resonates with me. It is that project managers need to “figure out what stakeholders perceive as success – and find a way to make the project live up to those expectations”.

This couldn’t be truer. If there is one thing a project manager is entrusted with it is the success of the project. We have wonderful processes, tools and best practices at our disposal. We’re full of knowledge on how to deliver on time, on budget and on scope. But no matter how closely we track to plan or deliver according to documented objectives, it’s what the stakeholders think that counts.

It’s the same with a company’s customers. Their perceptions are important. We’re all aware of how security breaches at major corporations have resulted in leaks of customers’ personal information. At the corporate governance level, this is dealt with by enterprise risk management programs. After all, what company, breached or not, would want its customers thinking their personal information was not safe? It’s like in the early part of the last century when people incorrectly thought their money might not be secure at the bank. A rumor would fester and, true or not, there’d be a run on the bank. Everyone would run to withdraw their cash and the bank would go under, whether it was in trouble or not. It’s a clear example of how perceptions, not factual information, can drive a failure.

Is taking a risk-based approach to managing perceptions starting to sound like a good idea?

When we analyze and assess risks, we develop a clearer understanding of the vulnerabilities of the project and the potential impacts of threats. We do this so we can make informed decisions on what to do about it. If an incorrect perception threatens the success of any part of the project, it behooves us to investigate and take action before it festers. Likewise, if negative perceptions already exist, why is this so? Perhaps there really is a problem.

Project managers need to test the pond water for smoothness and ensure the right perceptions are given off. Managing perceptions as a risk category is worth considering.

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].

Linking Change Management Processes to Projects Early

Written by Mike Lecky on November 14, 2007. Posted in Articles. 5 Comments on Linking Change Management Processes to Projects Early

IT projects usually represent change, so why aren’t there stronger links to the change management process at the formative stages of projects? Is there benefit to connecting the dots between business case approval, aligning the project portfolio with corporate objectives and change management? You bet there is!

There are many who would say that business cases need to be approved based solely on the merit of their benefits, costs and the risks associated with them. This isn’t wrong. But just because it passes this bar doesn’t mean the project should be given authorization to proceed. To make it onto the project roadmap the investment needs to be both viable and fitting to the organization. What does it mean to be both viable and fitting? It means that not only does the economic upside of the project have to be good enough, but the organization must also possess the ability to do the work (or get someone else to do it) and to make it pay off.

This is where integration with the organization’s change management process comes into play. According to a recent Tripwire podcast 35 to 50% of time in IT operations organizations is spent on unscheduled work dealing with poorly introduced changes.

Effective change management processes have several features that can help projects get off to the right start. Let’s first consider the progression from business case to project initiation and then see how this fits with the change management process.

Once the business case is shown to meet or exceed the threshold for investment, a project portfolio analysis exercise can be undertaken to assess the investment as being both viable and fitting to the company’s strategic objectives. The project is prioritized against other projects vying for the same total project budget dollars. Then it’s given a placeholder on the project roadmap. Having a placeholder means resources may be made available during a window for the duration necessary and to the extent outlined in the business case.

Has anyone had the experience of a business case understating the cost and duration of a project? Before the project is even initiated there is considerable schedule, budget and scope risk.

This is where an effective change management process can help. And assuming there are portfolio management practices in place, this is where it gets grey for many organizations.

Ideally, before that placeholder on the project roadmap gets inked in, a few things should be in place to keep the risk profile of the project low. First, an initial cut of the project estimate (perhaps budgetary only) and time line with a preliminary scope will confirm the early pre-project cost/benefit assertions of the business case. Second, the rest of the organization needs to be tuned in to the impact of the change.

Using the nomenclature of ITIL (Information Technology Infrastructure Library) the change management process is triggered by an RFC (request for change). This initiates several activities involving all potential stakeholders, internal and sometimes external to the organization, to evaluate the impact of the proposed change in their area. This is vetted by the change board which has significant authority over when, and how, a change request is incorporated into the working fabric of the business processes.

While approving a change is a formal process, the act of developing an approach to introducing the change is facilitative and change management offers an excellent framework to support project managers as they develop the project plan. Visibility and participation is higher when project planning is integrated with change management.

IT project managers win big time when solid change management frameworks are in place. The structure of many of their planning sessions is already served up in readily understood templates to identify and assess the impact of the change. The business wins because budget, schedule and scope risks are uncovered early by the broad audience of the change board. Finally, those involved in the business processes win because new initiatives large enough to warrant a project manager are now brought forward by the change process, giving them a voice early in the project life cycle.

Monitoring to Serve and Protect, Not to Play Big Brother!

Written by Mike Lecky on October 15, 2007. Posted in Articles. 6 Comments on Monitoring to Serve and Protect, Not to Play Big Brother!

Mike Lecky’s Monthly Blog

I’m becoming an advocate of independent project monitoring. This is because I believe it to be the one single thing that can be done, more than any other measure, to ensure projects contribute as expected and to keep projects on the rails.

Monitoring serves the project by providing objective assessment of performance. It protects the investment by uncovering problems and facilitating solutions to get things back on track.

Let’s face it there’s only so much value in reporting milestones hit and missed. This often is the sole product of the monitoring activity. Monitoring is much more. When done properly, it keeps abreast of the ever-changing business need and highlights disconnects in project scope as they arise. Monitoring tests the waters on attitudes and confidence that the project will be successful. Monitoring looks down stream and considers trends to highlight potential outcomes and issues.

The real value in having an independent monitor is that they’re more likely to cast light on risk triggers sooner. This can go a long way to paying their way! And we all know the additional overhead of an independent monitor can’t be justified without some payback. Knowing about risk events sooner is sure to improve their treatment, making them easier to avoid or mitigate.

In most organizations the health of projects is reported by the project manager based only on their observations and assessment.

What’s wrong with this picture?

Project managers are usually excited by progress and have a tendency to be optimistic in their reporting. And why shouldn’t they? It’s their job to keep it moving forward, to keep people motivated and spirits high. Yes there are other things they are responsible for, like reporting deviations from the project plan. Project managers can use all the help they can get. Since monitoring is a function that can add so much value, if done well, it seems logical to assign it to someone who can render independent, periodic assessments of health over the life of the project.

When selecting project monitors we should be looking for skills like collaboration, facilitation and observation and not action-based competencies like leadership and motivation. Monitoring is about observation, influence and collaboration. It doesn’t replace or interfere with the leadership provided by the project manager. In fact their relationship should be symbiotic and their skills complementary.

When things go awry a monitor can and should work closely with the project managers and other key stakeholders to influence outcomes and facilitate smooth project progress and alignment to business goals. The monitor confirms and enriches what the project manager reports and serves to broaden the circle of understanding of what is going on with the project and the project environment.

Independent monitoring is a great way to build collaboration into the management level of projects….and it has great payback!

Are all the arrows pointing in the

Written by Mike Lecky on September 13, 2007. Posted in Articles. 4 Comments on Are all the arrows pointing in the

Mike Lecky’s Monthly Blog

When it comes to keeping things moving in the right direction project managers could use a little help. Frankly, so could CIOs.

For project managers the challenge often is getting the right people at the right time.
For CIOs it’s about making sure the right projects are pursued at the right times.

People and projects. Two different sets of arrows in the company quiver. One common objective: to align project investment to strategic goals.

Wouldn’t it be nice if there were one single thing that could help both causes deliver on this objective?

Recently I spoke with a newly appointed CIO who observed that, when it came to IT-enabled investments in the business, there was no clear project roadmap, no decision premise and no visibility across the organization.

Hmmm… maybe if you throw enough money in, the worker bees will figure it out and something will come of it.

But of course that’s not what this CIO had in mind.

The idea – the project portfolio management idea – is to align investment with corporate strategy, and this means selecting the ‘right’ projects and prioritizing them accordingly. It means balancing available resources against business imperatives. It means adjusting project priorities to stay aligned with a continuously changing business environment.

It means other things too; mostly it means keeping all the arrows pointing in the ‘right’ direction, even when the target moves.

This is the aim of that CIO. This executive intends to keep project spending in line with the direction of the business.

Dreamer? I think not! A little structure and some process around maintaining a prioritized project list can go a long way to bridging the gap between strategic goals and getting the ‘right’ people working on what is best for the company.

That’s the one single thing to keep both sets of arrows, projects and people, aimed in the right direction; aimed in the same direction. A single sheet posted as a guide to all.

It’s a simple principle. Keeping it simple is important. Good thing senior management is starting to recognize this!

So how does this help project managers?

People are not like worker bees. We don’t simply and efficiently re-direct ourselves in synchronized buzzing harmony when things must change. We need a structured means to vector us. Project portfolio management gives everyone a premise to weigh decisions about work, and a basis to negotiate shared resources. What better way is there to get operating managers and project managers on the same page when it comes to re-directing resources to new priorities?

It’s win, win, win all the way! Project managers get a prioritized list of projects to gauge resource management decisions. CIOs get a defendable investment roadmap and a way to dynamically align projects to business objectives. And shareholders. Well, they get more value for their investment dollars.