By: Chris Vandersluis
I had the unfortunate experience lately of working with a very unhappy group within one of the federally funded agencies. As usual, I won’t bore you with who it was to protect the guilty but the experience has become so common around here that I thought I’d share it with you in this column.
The situation starts out like so many organizations interested in enterprise project management. Project management personnel and IT personnel, in an attempt to make the organization more effective decide that this can best be done through the implementation of an enterprise project management system. As with many other organizations, in this case, Microsoft Project Server was chosen. The particular flavor of project management tool though is almost irrelevant. What’s not irrelevant are the expectations that fell out of this decision.
A consultant was engaged that the organization believed knew more about project management than they did and this might well have been the case. The problem for this particular consultant was twofold. First of all, the expectation of the organization was that the implementation was largely a technical challenge and secondly that within a few short days (10 in this case), the consultant could transfer the knowledge of everything the organization might need to know in order to manage the environment on their own.
Three months later, this agency is no closer to a project management environment than they were when they started. The first consultant is gone and our firm was called in to do “rescue work”. I’m hesitant to say but unfortunately we do a lot of rescue work around here. The unfortunate aspect of my experience in this case is that despite the problems obviously experienced by this government agency, one of the lessons that clearly hasn’t been learned is to manage their own expectations. The conclusion that they arrived at from the first consultant is that he simply didn’t know enough technically about the product they were trying to implement and, if they could only have gotten some of their key questions answered, they’d be able to move forward at the breakneck pace they had originally anticipated.
The problem with these kinds of expectations is probably a natural fallout of how easy it has been to self-install software over the last 10 years or so. Personnel who are otherwise quite intelligent simply can’t understand what the problem is. You get a CD, you put it in the computer, you start using the software – right? As you know if you’ve been reading this column, installation of the software is only a tiny part of making a whole enterprise project management implementation work.
In this case we offered to send in a technical expert who could have gotten the whole environment up and running for a particular group in only a couple of weeks but the agency has decided they would rather train their own internal technical personnel who then should “be able to get the system running very quickly”.
The trend of the last 30 years is what causes so much grief to so many organizations. Going back to the 70’s when the first mini-computers were released, each generation of hardware and software has been easier to implement and has required less training and assistance to become productive. Implementing a Micro-Vax (remember them?) or a Unix mini-computer in the 70’s was a fraction of the cost of implementing a large mainframe and clients flocked to the new technology in droves. The releases of the PC in the 80’s became the next wave and now individuals with no formal computer training could implement systems. Windows in the 90’s made it easier still and product suites like Microsoft Office provided a phenomenal level of functionality which could be leveraged by plugging in a CD and then reading a book.
So what’s gone wrong? It’s simple really. The Internet which has provided such tremendous ease of use to network has resulted in global networking being ubiquitous. It’s always there. Prior to the late 90’s, getting networking working properly between disparate groups in an organization required serious technical work. Now, with the Internet everywhere, buying a laptop with built-in wireless likely means you can connect to everyone instantly.
The impact of this on the software industry and, in particular the project management software industry is that it has brought us full circle. Now the systems that are being demanded by the market are “enterprise” systems. Systems which leverage the connectivity of all people involved in the project management process. The progression of software interfaces means that the client-interface must be absolutely simple yet these products must allow the most complex of computing concepts.
Think about it. We say “We just want to update our project information over the .Net”. What we mean by that is that we want a browser view of our data. But we have some huge background expectations. We expect the data to be absolutely secure even though we expect to access it over a public network. We expect the data to be shareable with all other corporate data which means dealing with transaction conflicts at the database level. We expect instant access to the data. We expect never to have the results of another user affect our interaction with the data. We expect to see the data in whatever graphical or other interface is most convenient to us. We expect the analysis to calculate exactly what concerns us. We expect to have all of our systems integrated. After all, if I can see one system in Internet Explorer and then another system in Internet Explorer, why can’t they just be tied together? We expect the now centralized data to be useable by different perspectives such as Executives and Front Line employees not only coherently but simultaneously and so on and so on…. Whew!
What we’re describing is a lot more like a centralized mainframe or mini-computer system deployment of the 70’s than like the application suite installations of the 90’s. When you think about it like this, it’s no wonder it’s a significant effort to make these systems work.
When we train technical consultants for implementing enterprise project systems from inside our staff, we typically expect it will take 12 months from the time we hire someone until they are sufficiently advanced to be independent. The challenge for these personnel is the tremendous range of expertise that is required. To implement a product like Microsoft Project Server you really have to have a solid grasp of: Project Management Methodology, Change Management Methodology, Network implementations, MS SQL Server, Network Security, Web Security, Database Security, Microsoft Office, Internet Information Services, SharePoint, Internet Explorer and, let’s not forget, Microsoft Project, Microsoft Project Server, the Microsoft Project Web Access Interface.
Project Management Vendors like Microsoft work hard at trying to mitigate all these factors by providing as many defaults as possible in the software so that inexperienced technical personnel can get the system up and running with a minimum of difficulty but as soon as you have an organization that is a little bit larger or has specific requirements, you’re going to need to dip a little deeper into the technical barrel. This is what prompts Microsoft to so heavily promote its technical partners when talking about enterprise project management deployments.
If you’re working on an enterprise project management systems implementation, here’s something worthwhile. Call in a couple of different 3rd party experts for the products you’re considering. Tell them about your business challenges and ask them what your expectations should be.
