Important Things We Forget

In every technology deployment there are certain big things we focus on that make a huge difference in the quality of our deployment. Everyone has their eyes clearly on these elements and makes special efforts to ensure that they are right. Things like software selection, requirements signoff, customization development, testing, and infrastructure are always taken care of in any deployment. On the other hand, there are other aspects, that are also critically important, that seem to always be left till later, if they are addressed at all. These aspects, when overlooked, can be deadly to a transformation.

Why some things are never forgotten

Why are some aspects of a transformation addressed more readily than others? Well, indeed, some aspects are more glamorous than others. Some are blockers that prevent any movement until they are addressed. Some have a built-in constituency that assures that they get attention. And some are just so obvious that they are hard to ignore.

Why some things are often forgotten

Why are other critical aspects of a transformation ignored? These often represent less prestigious grunt work – thankless tasks - that while critical, are put off as less desirable to work on. There may be no natural owner, or the owner does not have the technical capability to address them. We often believe that they can slide for a while without impeding the main project. They are complex and there is not an obvious route to success.

What is forgotten

What are these aspects that we tend to ignore until later, and maybe too late. I believe a pretty good list is: Organizational Change Management (OCM), Data Migration, Support Documentation and Training, Business Continuance Planning (BCP), and Document Retention.

We forget: Organizational Change Management (OCM)

Organizational Change Management could be the poster child for this category of activity. I have seen cases where it was actively ignored as almost toxic. Yet it is critical to the success of even the smallest projects.

I believe part of the issue is that many in corporate management see this as ‘just doing your job’ and do not see that employees have a choice as to how they react to the transformed system. Of course, part of OCM is getting those same managers to see the importance of their role in OCM.

The key to success, in my mind, is to make OCM less nebulous and more concrete. Write down a risk analysis of how the transformation could go wrong. Share it with the stakeholders. Maybe try a pre-mortem analysis like we discussed in an earlier blog. Then build a detailed plan of how to counter all the obstacles - training, communications, new behaviors, or even annual goals for key individuals.

We forget: Data Migration

Although I love Data Migration, it makes most people queasy at best. A simple dodge is to claim that the Data is probably good enough and should not be a problem. Of course, all my regular readers know that your data is ugly – and probably uglier than you can imagine.

You should begin doing Data assessment and Data cleansing right now. Even if you have no plans to transform or change anything. Clean up your data! It is causing you to make bad decisions and, in some cases, can result in operational disasters.

At a minimum you should begin Data assessment on day one of a new project. Get some feel for how bad the issue is and make sure you allocate plenty of time and resources to address the most significant issues. The best policy is to fix everything in place in the source system, but if this seems too expensive, at least fix it as part of the Transform phase of Extract, Transform, and Load (ETL).

We forget: Support Documentation and Training

I can’t imagine how the support team lets this go time after time. (I guess it is because they are busy fighting fires caused by the last project that did not provide good support documentation and training.) They are also not the golden boys and girls of the IT world and, as such, find it hard to force the actual golden boys and girls to slow down long enough to provide what they need.

The support team is your friend. They can make a poor deployment go well because they are ready to jump in and fix anything that goes wrong. Make sure you allocate time to develop good documentation and provide training for them. It is not a bad idea to have them engaged in some of the testing, if you can break them free.

It is also a good idea to allow them to submit some ‘supportability’ requirements to the project scope. Many times, a few tweaks or scripts can give them a powerful edge in troubleshooting the system and making it robust and reliable. And don’t forget that error checking with readable error messages is always appreciated.

We forget: Business Continuance Planning (BCP)

Few projects look past the end of the delivery into operational issues. Fewer still look at what could happen way down the line in a total system failure. This is unfortunate because many of the decisions that are made in the project can severely limit the options of what can be done when a system fails.

Business Continuance Planning (BCP) has two main parts. There is the tradition technology-based Disaster Recovery Plan (DRC) that aims to get the infrastructure and application running again as soon as possible and the Business Continuance Plan (BCP) which describes how to keep business operations going as well as possible until the system is back on-line, and then how to merge back into the system from whatever workaround system was deployed.

If you create the Business Continuance Plan in the project, there are many tweaks you can make to the design to make it easier to both keep the business running and to help merge things back together once the main system is back in operation.

We forget: Document Retention

Some people see Documentation Retention as a minor legal issue, but it is becoming more important as lawsuits are using more sophisticated ‘discovery’ to find any history of ignoring product flaws. This is another aspect that is much easier to build in from the beginning, than to bolt on after the fact. A big issue is that most people focus on document deletion, but there is also a critical need to retain documents that are required. For example: for pending lawsuits that target specific documents.

Fundamentally each document has a lifecycle. It is created, used, stored, and eventually should be deleted. There are triggers for deletion. The simplest is time, but normally this is the time after some event, like the end of the product line production. So, the documents must be associated with a trigger and the triggers must be tracked and marked as expired or not. Periodically some sort of AI engine must evaluate each document and see if it is ready for deletion or not. They must also track snooze alarms set for specific legal actions or other purposes. In the end a little foresight can make this job easier.

Bonus issue: Privacy

An issue that is becoming more prevalent is privacy and personal data protection. This is primarily being driven out of Europe, but also has some domain implications like in health care. If included in the design phase, these issues can be addressed with a moderate effort. If the system is deployed and you try to bolt them on after the fact, it can become a huge expense.

Summary

All these issues are ones that tend to be overlooked or intentionally ignored in projects. When that happens, the issue can jeopardize the project deployment or worse yet can be pushed into normal operations where they just don’t have the time or resources to deal with it. Eventually it impacts day-to-day operations and costs the company money and possibly even reputation because it was not dealt with.

Conclusion

Do you have any other issues that tend to be overlooked in a project? Do you believe these issues are the main ones that become land mines in the project execution? Is one any more important than others or are they all risks to successful transformation? Please let me know your thoughts in the comments.

?

Digital Guideposts is written by Mark Pendergast – retired Data Junkie, Deep Thinker and Innovator. He worked with product data for over 30 years of his 41-year career in Automotive Components Manufacturing. His background includes work in Engineering, Operations and Information Technology. He is also an Electrical and Computer Engineer (BS-ECE) and a Certified Project Management Professional (PMP). In his spare time, he mentors a High School FIRST Robotics Team, reads and plays on his computer.?

?