12 Things to Get Your Portal to Production: Part 10 Change Management

Any project will have change.  No one project ever includes the entire scope or has complete buy in from all the stakeholders or goes off without some major issue.   That means you have to both budget for it and plan the process by which you will accept change.

Step 1: Don’t be Afraid of It

I’ve seen plenty of consultant and client project managers who are literally afraid to talk to anyone about a change which will have an impact to the project.  In a previous post on how not to run a portal project I noted that you will be up late at night trying to launch your portal if the PM has yet to notify anyone of a two month delay and the business thinks the site will launch in two weeks.  I’ve seen clients that are annoyed and I’ve seen them down right angry.  Down right angry comes from complete lack of communication.  In any change management process, you must work with the business and give them enough information to make a decision.   But the first step is to notify them of any issue and work with them to resolve it.

Setup a Process

Before any issues arise, you should define a process with the key stakeholders.  It needn’t be long or onerous.   You can even include some automatic steps for minor change.  But you have to setup a process that includes:

• Notification of an issue which will cause change and who should be notified.
• An agreed upon way of viewing the change
• Some process to define and approve your reaction to the change
• A way to include the agreed upon change in your project

What Should You Do

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Let me give you an example.

A few years ago I was working on an application heavy portal project.  One of the main portlet views required a sortable and filterable query which would display in a paginated result list.  This data came from a couple different systems.  The business had very specific requirements about which columns to display and how fast they wanted to display it.  One day my lead developer came to me and said, “Mike, I can either display all the data or I can display it in under 8 seconds but I can’t do both.”  It turns our there were some latency issues from the systems we were calling. Here’s what I did:

1. I took the time to understand the issue behind the latency.  That meant an extra 15 minutes from the developer.
2. I presented the issue to the client technical sponsor first.
3. Then I sat down with the business and communicated the issue and our inability to meet requirements.
4. I then presented a couple options that would let us resolve the issue.  Each of these options included pros and cons.
5. Perficient made a recommendation on what we thought the best solution was and why.  We told the business that the final decision was up to them but we had given them enough information to make that decision.
6. The business decided to cut a couple columns and actually thanked us for making the decision easy.

Now contrast that to other ways I’ve seen it done.

• The developer tells the PM that we cannot meet the display time requirement.
• The PM immediately goes to the business and tells them we can’t meet the requirement and their only option is to cut columns a, b, and c.  They have no choice in the matter.
• The business agrees after a lot of arguing or spiteful looks.
• The next time an issue arises, the business has no trust in the PM or the project team.

What about RUP vs SCRUM Methodologies?

RUP works with an official change project management process quite nicely as long as everyone understands that one of three things will change:

1. Project launch date
2. Scope
3. Budget

Typically what changes is the launch date or the budget or both. That’s ok. Many astute companies allocate extra funds for that type of change.

SCRUM includes the concept of change in it’s whole back log process.  Every time a 2-3 week sprint completes, you get a chance to revise the backlog and define what comes up next.  In this case though, what will change is scope.  You will complete something at the end of each sprint.  It may not be exactly what you wanted and you may need to work on it in the next sprint.   So you can introduce change fairly easily in both.