On the face of it, nobody should be using floppy disks in the 21st Century. Surprisingly, however, parts of the aviation industry still rely on these disks to manage airplane software.
Because airplane software is still distributed via floppies, most older airplanes have these disk drives built in to read and load from the relics. Certain airplane software arrived in sets ranging from 21-48 disks, with a technician loading them one disk at a time on the airplane. This was an error-prone process, and technicians required many hours trying and retrying to get all 21 or so disks loaded without the system timing out. Yet, when it came to eliminating floppy disks and changing it to a quicker, faster way of loading software, the technician’s comment was often along the lines of, “come back in 10 months, I will be retiring. You can change what you want then.” One airline rep commented that they have a stash of floppy disks that would be “wasted” if they transitioned.
Back in the day, a company I worked for decided to put in a new Case Management System, the system to log and manage customer issues and complaints. As a larger computer hardware and software products company, the organization of after-sales customer support represented approximately half the company’s work. It also had an entire eco-system of applications, add-ons, reports, extracts or UDAs (User Developed Applications). The current case management system was something everybody liked to complain about. The main reason for the UDAs was cited as the lack of features and functionality. In fact, replacing it with a newer, user-friendly one was the No. 1 request in a company-wide survey. Still, when it came to replacing it, most users wanted the new system to be exactly like the old one, flaws and all.
The first example is a technology change. The second is an IT system change. The common denominator in both is change. Surprisingly, most technology or IT projects don’t focus on Change Management. The people factor is largely ignored. These projects are run with a small-ish core group of people, the subject matter experts who define the requirements for the project, largely ignoring the vast majority of the people impacted by the project. It’s not surprising, then, that most of the technology projects end up with huge scope creep, or have many issues during roll-out and are inevitably perceived as disasters by the people impacted, sometimes despite meeting all the project goals.
When it comes to work, we are creatures of habit and routine. Most of us take pride in what we do and want to be known for excelling in it. We don’t like it when somebody changes things on us. Change represents a lack of control in some ways, which is why we resist it.
Change works when people feel involved and that they are contributing to the process. It works when people have the time to adopt and internalize the change. As the Project Manager involved in both of the referenced projects, I’ll share a few project management tips that help with managing these changes:
Create the vision
Start with the end state and draw it. And I mean draw. A picture speaks a thousand words. Use this as your reference to communicate the goals, breakdown tasks, report progress. Most people like to see the end-state at the starting point. As the project progresses, people want to see where they are going and how the journey is connected to the end-state. Consistently using the end-state as a reference will reiterate your key messages and also lend credibility to the project.
Break the end-state into achievable sub-parts or phases. Start with where you need to be and then think of what you need to do to get there. This helps people focus on what needs to be done rather than what is happening now, and also what can be done rather than that which cannot.
Don’t over plan
Be agile. Detail the phase in which you will be spending the most time. Add details to the later phases as you get closer to execution. The reason is three-fold: First, people get obsessed with dates and details and lose sight of the big picture. Second, too many details can cause you to lose the flexibility required to change your plan; Third, people remember dates and hold you to them - it’s easy to lose credibility when you are perceived to be missing deadlines.
Plan for a pilot, a prototype or a user experience focus group
If your project allows for it, start with a pilot. Or create a prototype. Start with a small group of users and monitor their experience. Incorporate the feedback in your plan or product. Agile projects lend themselves to an iterative way of development, where user feedback is incorporated in all stages of product development. However, user experience and feedback can be explicitly included as tasks/events in non-agile projects, if the project demands it.
Communicate, communicate, communicate
Most companies have existing framework and cadence for communications, formal and informal. Find the internal team meetings, the forums, the newsletters, the user groups, the task forces, the internal conferences. Create a project website and update it regularly. Spread the word and then reiterate it again and again through the life of the project. Get feedback. Follow up on questions and comments. This gives people the opportunity to be involved and contribute. Too often the change is too large with very little time for people to adjust and adapt. Early and routine communications give people the opportunity to adjust.
Yes, sometimes things get personal. Even the best project managers sometimes lose the fight with public opinion and perception. You can be vilified as a terrible Project Manager for the simplest of missteps, real or perceived. Recruit your management to provide air cover. You need an advocate or two who can speak on your behalf and defend you. Bolster your credibility by recruiting the folks with their own street credibility and engaging them in your cause. A few words from them can quiet the worst critic.
Don’t aim for perfection
Accept that you will make mistakes. Build the atmosphere for continuous improvement, for yourself, the project team and the project. Hold periodic reviews or lessons learned retrospectives and use these as opportunities for improvement.
To me every project represents change of some kind. It is important to understand the change and proactively plan to manage the change as part of the project planning.
Note on Change management:
Organizations embark on projects for various reasons: Adding new products, terminating product lines, creating new processes, introducing new technology, ID-ing new opportunities, addressing issues etc. Often, these initiatives require changes to existing processes, job roles, systems. This requires change in how the employees of an organization do their jobs. Ultimately, the success of an initiative depends on how successfully individual employees transition and adopt to the new changes. This is key for any initiative to deliver expected results. Change management should be part of project management. While project management ensures that the project delivers its intended solution, change management ensures that the solution is adopted and used effectively.