Avoiding the Top Five Traps of Technical Project Management

By Bob McGannon, PMP

Managing technology projects can be one of the most challenging arenas of project management. Ironically, it is rarely the technology itself that presents obstacles for the technical project manager. Being mindful of the most common traps that await the unsuspecting project manager can help ensure your technical projects don’t end up as financial disasters that don’t deliver expected function, and diminish the reputation of yourself and your technical organization.

1. It is about business process, not the technical tool

The intent of a project is to move the business to a better place. That better place can mean increased efficiency, additional capabilities or an improvement in the accuracy of the business’ output. Regardless of the nature of the business improvement, it is enhanced process that will drive the superior results. It is not necessarily as a result of a tool, a new IT system or improved technology – these are only the catalyst for the improved process which drives business results. Many project managers and their teams mistake the new technology as being the output of the project, rather than the enhanced process that results in conjunction with implementing new technology.

When the technical project manager keeps the new business process as the primary deliverable of the project many common problems are avoided. Divergence between the business processes the project customer wants or intends to execute, and the business process that is forced by a new tool or technology can lead to diminished project results. Those less than ideal results can include partial product implementation that does not fulfill all of its promise or in extreme cases a total scrapping of the project. Either way, the lasting result is a perception that the project manager and the team are out of touch and the team is more interested in playing with technology than moving the business forward in a meaningful way.

2. Moderate the amount of change your technology users must absorb

Many technology projects follow an all too familiar, rocky path. Adoption of new technology or new tools such as enterprise systems creates a learning curve for the technology team, and a “what IS this?” reaction from business users. As the project team and the customer struggle with this learning, time ticks by, and deadlines for project milestones loom large. Major deliverables are rushed, and are not fully understood except by a small subset of individuals. In some extreme cases, nobody genuinely understands the ramifications of the deliverables produced. As the final deadlines approach, large deliverables are put in front of the users, and they are expected to master (not just learn) the use of the new technology and the numerous process changes that accompany the slick new tool. Users throw up their hands in frustration, driven by the fear that they won’t be able to execute their job responsibilities come that “magic Monday” when the new product is put into the production environment. That fear eventually drives an emotional reaction to senior leaders, sending the project into chaos, or worse yet, the business itself faces chaos that is seen by external customers, tarnishing the business’ reputation.

The wise project manager breaks a large technology project into phases, not only to restrict the amount of technology the technical team has to master, install and customize, but, more importantly to throttle down the amount of change the business users must master in one pass. Think about when you have started a new job. In most cases, it takes weeks if not months to understand and feel competent in all aspects of your new position. Yet, sometimes the same technical people that take weeks to master their jobs make changes through a project that present a significant degree of change to business users, then expect them to behave competently with new processes and tools after a day or two of training. These business people suddenly face business expectations on the Monday morning after the projects deliverables are implemented with little to no “orientation.” This is not a reasonable path to business success. Make changes small and give your business users a chance to master the new processes as they unfold.

3. We understand the business better than our customer does!

No – you don’t. This misconception leads to a lot of problems in many organizations. Technical teams do have a unique and holistic view of the businesses they support, and often will have a view to the business that is not held by many of their customers. Mistaking this unique view as being a thorough knowledge of the ins-and-outs of the business processes and challenges your customer faces can cause a number of problems, including the de-emphasis of requirements verification meetings, reduced testing, and completely overlooking the need for some functionality or processes the business uses on an ongoing basis. Any of these can render the product of the project unusable, tarnishing reputations and costing significant time and money.

This is not to say that technical team members that have worked with a client extensively do not bring significant and important knowledge to the project team. Quite the contrary, these people are extremely valuable to your project. The wise project manager capitalizes on these experienced personnel for what and who they are – people that can provide critical direction as to the areas of the business that need to be consulted, and can assess whether changes the project may bring will be significant or simple to implement for the customer. These people are also vital in “bridging the language gap’ between the technical teams and customer personnel. The project manager must always remember however, that these technical people that have experience with the client aren’t the definitive “voice of the customer” because they aren’t the customer. The customer must appoint a representative that will serve as the final arbiter when it comes to issues affecting the customer environment, processes and schedules.

4. There are no “small” changes

As professed in a number of places and in a number of ways, change control is vital in technical projects, as in all projects. Because some changes are very trivial from a technical standpoint – for example the addition of a single line of code in information technology projects – the project manager can become lulled into a casual approach to change management. Don’t go there! Experienced and successful project managers remain diligent and committed to executing a sound and consistent change methodology. This helps ensure the integrity of the project deliverables, testing and product documentation.

As a means of “helping out your customer” and appearing to be reasonable and flexible, the project manager can have change documentation prepared by a technical project team member for signoff by the client. This is especially well received when the technical team came up with the idea for the change. Nonetheless, these changes should be signed off by the appropriate client representative and processed in an appropriate, methodical manner.

5. New function isn’t necessarily new value

People and tools can share a common characteristic – sometimes their strengths and their weaknesses are the same thing. In the case of people for example, one’s passion for technology is a strength that will lead to a passionate introduction of new tools to the business. By the same token, that same passion can be a weakness if they become too enamored with the technology, and utilize function that creates complexity instead of help the business users.

The wise project manager will put the business first and work with the client to understand what new technical functions they can best use and will introduce only those new functions that are viewed as adding value to the business.  In addition, it’s important to remember that a people process, vs. a technology solution, may be the best solution.  Just because a technology tool can be used to solve a problem, it doesn’t necessarily mean it should be.

Managing technology projects can be very exciting and rewarding.  By following the guidelines discussed here, your chances of implementing a successful technology project will be greatly improved

Bob McGannon is a Founder and Principal of MINDAVATION, a company providing project management services, leadership workshops and team building programs throughout North America, the United Kingdom, Australia and New Zealand. Bob can be reached at MINDAVATION via the web at WWW.MINDAVATION.COM.AU or by calling 866-888-MIND (6463)

The Mindavation Foundation is proud to donate 5% of profits towards development of youth leaders.
Copyright © 2011 Mindavation - All rights reserved.