Skip to main content

PMO: Change and Integration Management

Written by Cynthia Low on . Posted in Articles. 9 Comments on PMO: Change and Integration Management

Overview of the Challenge

What approach should be taken by a PMO to successfully introduce new processes and tools and have them accepted by the client group?

Research Findings

Generally, the by-product of a mandated change is an atmosphere of uncertainty, anxiety and even suspicion. The corporate culture resists being changed and that can both hinder productivity and render those tasked with integration less than effective.

My research and experience is based on what occurred when changes were required to document and integrate a manual which captured procedures and processes in order to perform tasks within a standard set of measurable parameters.

Previously, work was performed by qualified staff, but it lacked the rigour and discipline of standardization. An operational business model was required to meet the expectations of the customer (stakeholder) and to provide staff doing the work with an instructional manual.

Approach and Tools

Based on the PMI project life cycle (what you need to do the work) and the project management process (what you need to do to manage the project) the steps that followed were:

Initiating Process
The needs of the organization were determined, a project manager selected, existing systems, processes and historical information were reviewed. Stakeholders were identified, objectives determined, assumptions and constraints documented and a charter and preliminary scope statement developed.

Planning Process
The planning approach was determined. A finalized scope statement created and a team determined. Work and workflow (WBS, activity lists, network diagram, resources) were determined along with time and cost estimates. A schedule and budget developed and quality, standards, roles and responsibilities determined. Communication requirements, risks, procurements, process improvement plans, measurement baselines, approvals gained and a kick-off meeting held.

Executing Process
The team was acquired. Scope completed, information distributed and received, continuous improvement followed, team building and team management recognition done, selection of vendors determined.

Monitoring and Controlling
Measurements against performance baselines and plans conducted. Variances addressed. Scope verified and recommendations for changes applied following change control methods. Risks addressed and issue logs maintained. Each team member’s performance was measured and reported on. Administrative contracts maintained.

Closing
Closure procedures developed. Contracts closed. Confirmation that work was done to requirement and formal acceptance of product obtained. Performance reporting completed and archiving done. Lessons learned conducted and documented. Hand-off of product done and resources released.

And most of the time was spent planning.

Implementation Approach, Results Achieved and Lessons Learned

Although a comprehensive, easy to use, approved and accepted instructional manual was the end product – the experience and knowledge obtained through managing the change and integration of the product provided great insight for the project team (and project manager). Below are some of the challenges, lessons learned and resolution strategies that were applied.

Deciding Not to Change is Not an Option
Meet with the Resisters. Understand the ‘Why’ behind these people. Explain the “what’s-in-it-for-me” part. Listen and be supportive. Encourage, communicate frequently, let them vent. Introduce them to a Change Champion (a Power User who is your advocate).

Change Champions
These people understand the benefits and have the attitude of “I’ll make this work for me”. Keep these people close. Reward and recognize them. They’ll become loyal followers.

MBWA
Management By Walking Around. Talk to those in the trenches, be seen, understand their needs, feel their pain. Once they get to know you, they’ll become more comfortable. You’ll have a chance to stress the goals and the direction of project.

Pizza
The single, most powerful change management tool! If you feed them, they will come. Conduct lunch and learn sessions. This informal setting offers a great forum to educate the users aside from the regular training sessions.

BLOG/Communicate
Keep communication clear and concise. But always communicate. Be honest. Address all issues ASAP – the good, the bad and the ugly. Especially the bad and the ugly! Keep an on-going issue log. Let the clients see the progress, and that you actually care about their issues and are working on a fix for them.

Your Dysfunctional Family
Do you have the right project team in place to deliver the project? Everyone brings something exciting to the party. However do you have the correct combination to successfully implement the project? A square peg in a round hole just causes grief for everyone. Make a change of staff if you need to. Everyone wins then.

How Good Are We?
You can’t manage what you can’t measure. Determine your success criteria and aim to meet or exceed it. Track your progress. Celebrate your successes with the team.

Become Roommates
Ensure your objective is not to ‘Cut and Run’. After change and integration, remain with the clients at their location, even if it’s just for a few hours. If there are problems or concerns, you are there to provide assistance or refer the problem up the line. Don’t walk out, leaving them resentful, at a loss and with no one to contact. Not only will it impact their daily work but also your reputation.

What does the PMO have to do to be Successful? Setting up for Success!

Make sure the odds are in your favour. Do what you need to and ensure you tip the scale so the odds for success are on your side.

  1. Listen very carefully to management. You can give them what they ask for, but is it what they really want/need?
  2. Be an expert – not a know-it-all, but a trained professional. Seek out the training you and the team need to accomplish the project.
  3. Keep your promises. You committed to a budget, schedule and staff development. Deliver!
  4. Never compromise your integrity. Ever!
  5. The greatest motivation act one person can do for another, is to listen. This applies to both your team and your clients.
  6. If you can laugh together, you can work together. Enjoy your work in project management and the people you work with. It will make life a whole lot simpler and less stressful.

And trust me on the pizza!!

Donna M. Ulrich, PMP has over 25 years of project management (in various capacities within projects) and consultant (owner of Cougar Management Consulting Corporation) experience, with the proven skills to deliver all aspects of projects, including strategic planning, staff management, training/development, process improvement, change management and customer satisfaction within the nuclear, telecommunications, IT, service/utilities, financial and healthcare industry. When not managing projects, Donna enjoys kayaking, reading, movies, theatre and travelling. Her favourite activity though, is being with her daughter Samantha, and Noah – the wonder-dog! Donna can be reached at [email protected]

2008, Donna M. Ulrich, PMP

It

Written by Cynthia Low on . Posted in Articles. 5 Comments on It

For many years, one of the challenges with technology was to think of software ‘packages’. This pervasive way of thinking inevitably brings us to thinking of software as a collection of features. We even compare one product to another by listing the features on one side with the features on the other.

The idea of having software as a series of interrelated parts that could be made into plug-and-play components of a larger system often meant we would need to do lots and lots of programming of the interrelating software. Our company has focused on solution selling for years, so for us we’re used to asking a client for the problem before we list the solution. But it does make us think around here of software more as a vehicle for creating a solution, rather than a list of features that the client might find attractive.

In the last couple of years, however, there has been sufficient movement in the software business towards more common standards that we can start to think of technology as a “stack” of functionality, and interact with it as the potential for a solution, rather than the fixed list of what can be delivered on the first day.

I recently presented some project management software to a rather large company with a worldwide brand name. This company certainly has extensive project management experience but in the particular division I was interacting with, project management had always been an ad-hoc or project-by-project notion rather than centrally organized. The division’s volume of work has recently increased, however, and the complexity of that work has grown by an order of magnitude. It’s time to make project management a more formal process.

So, I showed them this software, which was rather well received. I showed the software as I often do, after extensive conversations about what the company is attempting to accomplish. Once I’d done the presentation, I turned off the projector and told a story.

“Imagine,” I said, “having to create a new project. You wouldn’t turn on the software we’d just shown you. Instead, you’d click on a link on your corporate intranet portal. The link would present a web-based form for new projects. You’d fill in this form on your terminal. You wouldn’t need specialized project management experience. You might not need to know how to create the schedule and establish the dependencies between tasks, or what a lag is, or that CPM stands for Critical Path Methodology. You’d just fill in this form.

”Depending on who you are, the form might look different. If you were a senior executive for example, certain parts of the form for approvals might not appear. Other parts of the form might only appear depending on other data you’d enter. If the project details you entered had, for example, a place for the cost of the project and that value was, say, more than $100,000 then another part of the form might instantly appear with additional fields of information required to start a project of that value.

“Now, imagine once completing that form that you click on the ‘Submit’ button and depending on who you are, and the data in the form, it is automatically sent to the person in your organization who needs to approve new projects. That person would receive an email in their Inbox. They might see the whole form there or click on a link to the form online in their browser. They would see what you had typed in but they might also see other information. Perhaps they can see right on the form, for example, the value of the project you typed but also the total value of the budget that has been allocated so far for this year. They would see different buttons on the form such as ‘Reject’ or ‘Request more details’ or ‘Approve’ or ‘Forward for approval’. They would click on the ‘Approve’ button and several things would happen. First you would get an email saying that the project is now approved. In your Enterprise Project Management system a new project would instantly appear. It would have the data from the form that you filled out. There might even be a very high level schedule of milestones if those were required in the form for new projects. The stage for the stage-gate methodology would be set to “initialized”. Other key people might be triggered by that event to create certain project documents and so on and so on.

“Now we can do the same thing with change management, budget approval, resource allocation etc.”

There was nothing on the projector. It was a story. But the story was compelling.

“That’s just what we need,” said the representative of the organization.

All of this has become possible and not just with one tool. In fact, if you wanted to make my story into a solution, there are several tools you’d go to look for. They might come from the same vendor or from several vendors.

You’ll need a server-based enterprise project management system of course. That’s a good starting point and there are a number on the market.

You’ll also need server-based workflow engine. Again, there are several on the market that are quite excellent and can be configured without having to be a programmer.

You’ll need a forms-generator for online forms to be able to create intelligent forms that can take actions in the background. Most workflow vendors have such forms-based tools embedded in them or attached to them, but most workflow tools can work with numerous forms tools.

This interoperability is all thanks to the ubiquitous presence of the Internet and the movement from older client-based systems to server-based centralized systems. This has prompted more and more vendors to open their technology. We hear more of the terms “Software as a Service” (SaaS) or “Simple Object Access Protocol” (SOAP). The movement towards Software available as a Service means that whatever functionality is available can be used by different interfaces to create blended functionality. The standard of SOAP and other such protocols means that everyone has a standard syntax and grammar for communicating between products. The end result is the potential to combine the functionality from where you can find it into the solution where you need it, and that’s all possible today.

That’s all the good news.

I know. You were waiting for the bad news weren’t you?

The challenge is what’s implied in my story. The workflow sounded wonderful to my client but, if I want to implement that technology, we need to know what the workflow is. That implies a standardization of process that everyone in the organization agrees to. As I’d mentioned earlier, this particular organization had managed projects in a very casual ad-hoc manner. So getting consensus on what the new project process might be will almost certainly take some work, and consensus is key. Also, we can, in theory, proceduralize almost anything, but the law of diminishing returns takes effect in here somewhere. There will come a point where making a formal automated process of one more procedure rather than leaving it to be managed casually won’t produce any more efficiency. There needs to be someone central to make the decision on what that point is.

Who will make the final decision on what to proceduralize? Who will have the final say on what a particular process will be? What will be the process to change or add to the process? If the processes we’re discussing will touch several departments (such as Finance, or HR) instead of just project management, then who will be the liaison for those departments? Who will be the keeper of the process? What is their authority in the organization?

This is why, when I talk about enterprise project management and what’s possible, I inevitably talk about it as a change management project rather than as a technology project. At its core, we’re asking the organization to change how it works and possibly how some core aspects of how it works. That change is always going to be a bigger challenge than the technology required to deliver the solution.

What’s important to know? That it’s now possible to blend these technologies together and as a result bring the project management process to levels of the organization that will never see or need to understand a GANTT chart or a PERT diagram.

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]. This e-mail address is being protected from spam bots, you need JavaScript enabled to view it.

And the Rant Goes On!

Written by Ilya Bogorad on . Posted in Articles. 12 Comments on And the Rant Goes On!

In my last blog, I complained about how the two words “Project Manager” can mean such different things to different people. Let me continue my rant on perceptions of the role of the project manager. Well, first of all, why am I making such fuss about this? Because it is just too important to ignore!

A few years ago, at the time of my getting pretty bored with my well-paying full time job, I read Peter Block’s famous Flawless Consulting. The most important thing I learned from it follows: happy and prosperous consultants never position themselves with client as a “pair of hands”.

Far too many of my colleagues in project management are happy with the “facilitator” role. They maintain project schedules and set up meetings, keep minutes and file timesheets. I don’t know why anyone would like such a mind-numbing, boring, low-value job. Fine, perhaps, for a young kid right out of the school, for a short time, just to figure out how the corporate world works, but for a mid-career professional? Please!

I sometimes receive calls for recruiters and am constantly amazed how low project managers’ rates have fallen! I recently heard that banks pay as low as $60,000 and that it is dragging the whole market down. Except, if we are talking about the facilitator role, 60K is just too generous. I can get a clerical person do the same job for much less than that.

What makes sense to me, in terms of positioning, is the “taskmaster” project manager. As an executive or a project sponsor, I want to see someone stepping up and taking on the responsibility of running a project for me. There are clearly defined boundaries, and if the issue is outside of them, I am made aware and expected to provide guidance. This is a partnership, and I rely on the project manager as much as he or she relies on me. A good taskmaster is worth a lot.

The positioning of the project manager as a “mover and a shaker” is appealing and potentially very lucrative, except that:

  1. If such expectation comes without true empowering, which is often the case, the project manager will certainly under deliver (and possibly shorten his expected lifespan).
  2. Inevitable risks outside of the project manager’s control become the project manager’s problem. How do I control things outside of my control? This can get very stressful.

These points are so serious that I would never take on a mover and shaker role unless I have dealt with these issues, no matter how much I like the feeling of making things happen. And I like this feeling a lot!

The Proximity Principle: Continuous End-User Involvement and Project Success

Written by Claude Emond on . Posted in Articles. 15 Comments on The Proximity Principle: Continuous End-User Involvement and Project Success

In my previous blog entry, I mentioned the importance of managing perceptions. I also wrote that not doing so was the main cause of why only one project out of three was considered successful by major stakeholders, according to the Standish Group’s Chaos Report 1.

So, if we have to manage perceptions, where and how should we start doing that? The Chaos Report gives us pretty good leads on that, so, I am still amazed to find in my project management workshops that not even one participant out of 100 knows about the Chaos Report, its contents and conclusions (based, by the way, on data and observations on thousands of projects).

The report identifies the involvement of end-users as number one in its top ten list of key project success factors. Yet many project managers and their sponsors still shy away from this obvious tip. On too many projects still, project managers meet, at the start of the project, some so-called representatives of these ultimate project customers to discuss rapidly THEIR operational requirements. They will not be in touch with end-users again until much later in the project, only to find a very uninformed, displeased, and distressed party in full “resistance-to-change” gear. There is then a lot of damage control to do to regain end-user trust and ensure that they will commit to materializing project benefits from the deliverables “imposed” on them.

End-users involvement must be more than that. Successful project managers have long realized that, in this changing world of ours, customers/end-users also change their mind along the way and must also understand that conditions in the project environment change for all sort of uncontrollable reasons. Both project managers and their ultimate customers must be ‘in sync’, preferably in a continuous manner, in order for the former to satisfy the latter.

Ensure with your sponsor that you get proper end-user representatives on board and keep them involved in your project as it evolves. I call that the Proximity Principle and its functioning is quite well explained by Scott Ambler in his landmark article: Agility for Executives 2. Do that and you will automatically get high quality deliverables (and highly satisfied end-users perceiving the same deliverables as you), while keeping the risks of not meeting requirements as low as possible. Do this also with all other major stakeholders and you will effectively manage perceptions and deliver successful projects over and over again.

1 www.projectsmart.co.uk/docs/chaos-report.pdf
2 http://www.ddj.com/architect/184415034?cid=Ambysoft

Creativity Cannot Be Scheduled!

Written by Mike Lecky on . Posted in Articles. 10 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.

 

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]