After Erik Eckel's IT consultancy finished a challenging server migration project, they conducted an informal review, which revealed four PM lessons.
There's a temptation to believe that after working five, 10, or even 15 years or more as an IT professional your systems, techniques, and practices are well-honed, finely tuned, and efficient. That would be a mistake.
The technology industry, for better or for worse, changes incessantly. It's a grinding machine of new applications, innovative programming, changing landscapes, and shifting trends. Many professionals enter the field because it's ever-changing, always challenging, and highly impactful.
But such combinations also breed complacency with the most basic of business fundamentals: project management skills. Just because you perfected systems for servicing clients, migrating servers, and deploying new networks three years ago doesn't mean those same systems are working well today.
One recent server migration, which proved challenging at most every conceivable turn, reminded me that IT consultancies must assume nothing, take nothing for granted, and trust no one (including clients, third-party software providers, and any and all intermediaries). To ensure our consultancy continues delivering high levels of client satisfaction, we performed an informal review following the episode, which subsequently revealed these four project management lessons.
Project management plans must be flexible
My office's original task was to replace a six-year-old Windows 2000 Server. The box was the only network server, providing Active Directory, DNS and file, print, and application services to 20 clients. The client requested that the new machine continue running third-party business critical applications but also possess the ability to accommodate a new platform the office was considering deploying within two years, so we ensured all hardware requirements were appropriate. In addition, we had a sound data migration plan in place to enable continued operation using existing software.
To be safe, we contacted the third-party (business critical) software manufacturer to ensure the new hardware would prove acceptable. We were told in a phone call that the system and the configuration would, indeed, meet requirements. We contacted the vendor on a second occasion to confirm the new OS we would deploy (Windows Server 2008 64-bit) was compatible, and we were told that the OS was compatible.
So we bought it, and then we went to deploy it — that's when the trouble started.
Timelines changed; the old server began dropping disks within its RAID array; viruses infected a critical client; and backups were at risk of becoming corrupt.
The project quickly changed from a standard deployment to an emergency maintenance initiative with a new primary goal of avoiding data loss and preventing downtime. We were able to correct all issues and make necessary adjustments to complex compatibility issues that arose with the server, only because we made frequent on-the-fly changes to our project management plan. This is an important lesson to remember: Projects change and the corresponding project management plans and communications systems must support such adjustments.
All requirements and dependencies must be provided in writing
I'm not the guy who gets everything in writing. I hate doing business that way; some of my best multi-year long-term maintenance clients agreed to their contract terms with a handshake.
Unfortunately, I'm learning you can't do business with everyone that way; this last server migration project is one such example. After two engineers contacted a third-party software vendor (who is well known, incidentally) for assurance that the equipment we were deploying was compatible with their product, we discovered multiple incompatibilities.
Long story short, we had to purchase and deploy additional internal RAID arrays, change OS version, and more. We didn't get our confirmations from the vendor in writing; instead, we found ourselves arguing over conference calls as to what we were told. One conversation actually had the vendor telling the client and us, "We show a record that you called. We show a record that you asked to confirm the compatibility of your operating system. We show that we answered that question for you. But do you have proof we told you Windows Server 2008 64-bit is compatible?"
I swear I don't make this stuff up.
The lesson to learn is cover yourself by obtaining all hardware requirements and dependencies in writing.
Checklists are a necessary evil
Organization is the key to project management success. While consultancies don't necessarily need to deploy sophisticated solutions such as Microsoft Project, Intuit's QuickBase, or 37signals Basecamp, you do need written project management plans, and checklists should be a part of those plans. Smaller consultancies may perform well using simple timelines and checklists.
Help is out there. Erskine Labs' Jamie Pittock has published tips on using Basecamp to manage projects. Such Web collaboration is a simple way to empower teams and keep projects.
A new book that's quickly making an impact, even though it's not published yet, is Atul Gawande's The Checklist Manifesto. Look for it in January.
Clients must understand their technology needs
Sometimes trouble arises because clients simply don't understand their technology needs. One important aspect of project management is to ensure your clients understand their own business needs and objectives and how those needs and objectives translate to technology requirements.
Clients talk to others about their technology needs, and, inevitably, clients are told there are easier ways to do things than what you've proposed.
I'll give you an example. Say a cosmetic surgeon speaks to a friend who provides advertising services. The advertising executive may say it's easy to create a Web site that enables prospective clients to complete a simple Web form that submits their name, address, telephone number, and informational needs to the agency via email. The process is fairly straightforward and low cost. Then the physician might share his own cost estimates (the ones the IT consultant provided) with the advertising executive. The cost will strike the ad exec as exponentially more. He/she may then conclude the surgeon would receive a bad deal were the surgeon to work with the IT consultant.
But that's not true. The IT consultant, when working to provide the same functionality for a medical practice, must implement SSL communications, ensure all correspondence is HIPAA compliant, etc. IT consultants must ensure they explain how a client's specific needs and requests translate to technology requirements; otherwise, you leave yourself open to second guessing.Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!