Enterprise systems best practices

I mostly write about enterprise timesheet or enterprise project management systems and the most common phase of deployment that I talk about with such systems would be either the selection or configuration phase; talking about the strategic perspective. This article is much more about operational practices and isn’t specific just to enterprise timesheet or project systems but about enterprise systems in general though the subject matter certainly relates to enterprise timesheet and project systems.

When we encounter deployed project systems or we talk to existing clients who have our TimeControl timesheet system, we often ask questions about how the organization deployed and have supported the system and its environment. When we got started in the industry, these were simple conversations because the software we’d install would always live on the end-user’s PC and care of the system was always a local concept. These days that’s rarely the case. Enterprise systems are simple at the interface or display level where end users can typically access the functionality through a web browser in what looks like any other web page. As simple as these systems might be in front is as complex as they might be in the back. The technology required to display that interface likely has numerous layers, depends on multiple sources for the technology and infrastructure and if that’s not enough, is probably being updated all the time.

But, there are some basic best practices that can give you the best chance of maintaining a high degree of reliability in your enterprise system:

Find an owner

In fact, we have to divide this into two owners because any successful enterprise system has both a business owner and a technical owner. Only when the business owner is an executive in the IT department and the enterprise system is primarily for that department can the owner’s be the same. So, let’s take this in two parts:

Find a business owner
This person should be an executive level or senior management level person who has a vested interest in the results of the system. The benefits that the system must deliver or the business challenges that the system must overcome will have to be benefits and challenges that affect this executive directly. And, before someone even says it; no, typically it can’t be a committee or multiple people. The responsibility has to lie somewhere. This person might also be the
executive sponsor for the implementation of the system but might not be. Often the executive sponsor is not the ultimate business owner of an enterprise system. Even after the deployment project is over, the business owner will still own the system and, should they no longer require it, either another business owner needs to be identified and must commit to the system or the system should be retired.

Find a technical owner
For enterprise level systems, just having a technician available is insufficient. Remember, enterprise systems depend on many layers of technology. The technical owner must be a senior enough manager or executive in the IT department that they will be able to immediately interact with the owners of those other layers of technology. That may include senior people who own the database, the database server, the application server(s), the networking, the Internet connection, the firewall, other Security systems, the client-level operating system image. Someone senior must be able to represent this enterprise system to those managers who control other aspects of the environment.

Be purposeful

Make sure that the enterprise system a) has a purpose and; b) is fulfilling its purpose. All too often enterprise systems are acquired for the wrong reason and it falls to someone in IT to look for a purpose to apply the system to. The person signing off on the business purpose for the enterprise system should be the business owner though others might be involved. I always ask such executives a question I’ve used for years, “What business decision can you now not make or can you only make with great difficulty, the making of which will be enabled by the deployment of this system?” Once the business requirement (note that I didn’t say the desired functionality) is
settled, make sure that the enterprise system is actually fulfilling that requirement. We get a lot of people who have a shopping list of functions but little understanding of what they’re trying to accomplish with them.

As the organization evolves, make sure that the business owner comes back to this basic concept. Just the deployment of an enterprise system can fundamentally alter the business it is deployed into so it’s not surprising to find that the organization’s requirements for a system can change.

It is common to come into an organization several years after an enterprise system was adopted and deployed only to find it impossible to locate someone who knows why it is important to the organization. The system is in use to be sure. It is being carried forward on sheer inertia but the purpose has been lost and the executives who benefit from it every day don’t realize where that benefit is coming from.

Get it into your enterprise architecture

Several years ago I remember going with one of our technical staff to an upset client’s location. The deployment of an enterprise system we had sold them was unstable and causing all kinds of upset. While there in person, we asked to interview a number of technical personnel, tracing the system back through its layers. When we got to the database layer, we were stunned. Instead of being one of the organization’s standard database servers, the database on which they’d installed the system was on an end-user’s PC. Every time they rebooted, turned the PC off or installed something, the database would become unavailable. This affected literally hundreds of end users.

The organization was a large one so there was no lack of enterprise servers or infrastructure to rely on. In this case, the problem was easily fixed. It was a good lesson though. Is the system you are deploying being woven into the existing corporate infrastructure on which the organization may have spent an enormous effort getting stable, being reliable and being secure?

Back it up

I know, this is silly right? Amazingly and unfortunately it’s not. Enterprise systems can be notoriously complex to back up as they may depend on multiple aspects of the system to be backed up at the same time. There is the basic data of course, but also the meta data, configuration data of the implementation and any related data from ancillary systems that might have to match the system might have to be part of the same backup scheme.

And just backing up isn’t enough. When the systems change or are upgraded, do a database restore at least once. I remember years ago being with a client who we had helped design their backup strategy for. He shut down the server, pulled out the hard disk, put in another hard disk and then looked at us and said “There. The hard disk just crashed. That’s a newly formatted hard disk. Please restore my system.” I was taken aback but moreso because I realized how good a request it was and the more I thought of it, the more I realized how shocking it was that no one had ever made the request before (or since). So, do a restore test at least once. We were able to restore that system by the way, but it didn’t go back in as cleanly as we’d suspected it would and we had to update our backup procedures.

Staging/Production

“All the world’s a stage, And all the men and women merely players;” said Shakespeare a long time ago. In this case those stage is more about staging and that’s key to for any enterprise system. Once the system is in production, you will want to try new configurations, add new customizations, try new reports, links, fields and other changes. You’ll have updates and upgrades and all of these should be tried first in a staging or development environment before they’re inflicted on the users in the production environment. Something as basic as a browser update or a database update can throw enterprise systems for a loop so make sure you keep and maintain a staging environment that’s separate from a production environment. In this day and age of virtual servers this may be easier than it might have been in the past as an entire environment can now often just be cloned from the production system but that may be easier said than done depending on how you’ve deployed. Remember lots of different parts of the technology puzzle may be referenced even though you’ve copied an entire server.

Monitor, monitor, monitor

There are lots of points of oversight that can be used to monitor an enterprise system. First of all, making sure it is “up” or available is critical and ensuring that the appropriate technical staff are notified as quickly as possible if it is ever not available is also essential. Thankfully there are many tools on the market for ensuring that the system is functional and available that can automatically notify technical staff even if end users haven’t noticed the problem yet. But there are other aspects of monitoring
that are also important. It is good to keep a watch and a log of the health of the application including the amount of memory it is using, the amount of the CPU(s) it is taking up, any errors that the system may have reported even if it recovered from them itself, any restarts of the server required and the relevant health of other elements of
the technical infrastructure. Knowing, for example, that the Web Server is having technical issues might be very important to maintaining the availability of your enterprise application.

Even small changes are changes

The technology on which enterprise servers are based is changing day by day. It’s impossible to avoid all of these changes. Server operating systems often receive updates every few days, databases often receive updates every few weeks. Client operating systems and the browsers and their add-ins get updates every few weeks. Any part of the chain between the data and the end user is a potential point at which the application can break down so create a structure to manage changes throughout the entire stack of technology. This can be a challenge as many different enterprise applications may depend on similar aspects of the stack. We had one client who innocently updated their own enterprise project management system awhile back only to find that their entire collaboration server was brought down. The effects were devastating and took days to
reverse. At another organization, we had a client who had updated another enterprise application to find that it absolutely required all users upgrade their browser version only to discover that other enterprise applications already in use at the company did not support the more recent browser version. It was the proverbial rock and the hard
place. In the end, they had to roll back the upgrade of the enterprise system and wait until all the enterprise applications could move forward with a new browser upgrade.

Sometimes it’s better to look integrated than be integrated

Sales demonstrations always make the integration of multiple tools look so easy. Hey presto, the data starts here and ends there! Establishing a link between disparate tools is tough enough and we always recommend that both systems be in production and stable before any links are established. Once they’re underway however, it’s even more important to monitor any changes of the two systems with a mind to making sure they will continue to link properly. With any upgrade of either system, there may be data changes, structure changes or different technical requirements. There may also be new features and benefits that are possible but make sure the existing linking functionality is tested in your staging environment before it’s rolled out to production.

Document, document, document

The people who were there when the enterprise system was selected and deployed won’t be in those roles forever. In fact, if they did a great job, they’ll be off managing the next enterprise deployment the organization needs. So, documenting the configuration decisions, the projected benefits, the operating expectations and parameters that were used to make those decisions is essential. Others in the future will be looking at this system and scratching their heads saying “What were they thinking?” Make sure you tell them.

Enterprise system documents should be living documents that are updated with every upgrade, each change in business or technical owner or any major change in either the operating structure or the business requirements.

Look before you leap

It’s the advice we give people diving into a murky lake for the first time. Is it shallow? Are there rocks just below the surface? Enterprise systems can indeed bring complex data elements into one place where decisions based on that data can be more effective and the benefits of those decisions can make a profound difference to an organization. But you need to do your homework to ensure that you are operating your enterprise system in a way that you can get the benefits you need without exposing your organization to costs and risks that can quickly wipe out the value of those benefits.

Archive: March 31, 2011

It’s an all new calendar page!

Enterprise systems best practices

Next Microsoft Project Conference is only a year away!

Dilbert on Project Accounting

Selling Project Management to a sceptical executive