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 a particulare project management software product or service. It is, instead about enterprise systems in general though the subject matter can certainly relate to almost all enteprise project management system deployments including our own TimeControl timesheet system.
When we encounter already deployed enterprise project management systems or we talk to existing clients, we often ask questions about how the organization deployed and have supported the system and its environment. When my own firm, HMS got started in the industry, these were simple conversations because the project software we would 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 project management 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 and that almost always means one person. 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 that the database resides on, the application server(s) that the enterprise project management system is installed on, the networking, the Web Server or Server farm, the Internet connection, the firewall, authentication servers such as Active Directory, Security servers or systems, and 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 enteprise system:
a) has a purpose and;
b) is fulfilling its purpose.
Sound obvious? It’s not. All too often, enterprise systems are acquired for the wrong reason or for unstated reasons 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 talk to 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 like Project Server 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 project management system was 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, usually at a minimal level. 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 enterprise project management system they had installed themselves was causing all kinds of trouble. 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 version on which they’d installed the system was on an end-user’s PC. Every time this end-user rebooted, turned their 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?
One of the most challenging things we’ve had to learn about enterprise architecture is making sure we are seeing a complete picture. We’ve had numerous instances when technical people who understood the entire architecture weren’t invited to key design meetings because the organizers didn’t think their presence was required. As a result, we’ve experienced issues during deployments when we suddenly discovered a new security layer, a malware protection appliance, unchangeable firewall settings and the like. Make sure you’re getting a complete picture before you deploy.
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. When we think of an enterprise project management system, we have to think of backing up not just the project database(s) but also the system data. In some products we might have to ensure that some data saved on individual PCs is also backed up. This requirement doesn’t evaporate if you’ve decided to go with software as a service. What is your disaster recovery plan if the service you’re using suddenly becomes unavailable?
And just backing up isn’t enough. When the systems change or are upgraded, do a database restore at least once to ensure the backup process is working properly. 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 project management 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 “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 your enterprise project system is available to end users 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 modern day enteprise project systems is based (including TimeControl) changes day by day. It’s impossible to avoid all of these changes. The operating system can receive updates every few days, the database server software can receive updates every few weeks. Individual client operating systems, their virus scanners, firewalls and browsers and the browser’s add-ins get updates on a regular basis. 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 project system awhile back at the recommendation of the vendor only to find that their entire document management environment was brought down as a result. Clearly we thought, there’d been an error in how the update had been applied. In fact, there was an inconsistency between the underlying requirements of the enterprise project system and the document management system and upgrading all the underlying components of one system, made it impossible for the other to work properly. While there were complete backups and no data was lost, the upgrade process did not have an instant rollback provision and thus the effects were devastating as it 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 highly flexible tools like your project scheduling system and other enterprise systems like Finance/ERP 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 project management 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. Here at HMS we’ve taken to documenting the process internally and often we are the ones who can inform the client years later what the driving requirements were for the deployment of TimeControl as the enterprise system.
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 project management 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.
Note: A version of this article was originally written for and published in Microsoft TechNet.
