On Process Etc.

“What obstacles do project managers face to successful completion of an Information Technology project?”

Information Technology and Services Professional

Every project is unique, and even the same project in two different companies is also unique. However, from personal experience, these are the biggest gotchas....

1. Ready, Fire, Aim! - Spend time BEFORE you begin. Amass all of the information, scope, expectations, deliverables, etc. If your project is successfull, it will expand. Leave room to grow at the end without having to start all over from square one.

2. Expect resistance. As the PM, you have had potentially years to understand the change(s) coming. Thus, you are comfortable, whereas the end-users are being force fed very quickly. Where possible, have end-user driven meetings answer questions, provide updates, and anticipate how much help you will need come launch day

3. Change orders - These are ineviteable, but don't let change become the project. Group them into categories (e.g., critical to launch, SP1 Priority, or simply nice to have) and move on.

4. For large or complex projects, I liked to hold "Proof of Concept" testing where possible and let the end-users be the testers; and audit or risk management as the lead. Why? A) Proves it can fly; b) Gives the end end-users a chance to fly it too; c) Get's Audit or Risk Management involved and hands-on; d) Provides an early look into ease of use or where training may need to focus (just be clear on concept versus final product to address misconception; e) Let's someone else test and document so you can keep the project moving; f) allows you to observe instead of drive; and g) Hope for failure somewhere. If the first "pre-test" is perfect, something is definately wrong!

5. Budget busters - "measure twice, cut once". Upgrades always have gotchas.......plan for them in contingency funds up front. Anything totally new is either very simple and straight-forward; or your worst nightmare come true when it now won't run on the old routers you forgot to consider.

6. Build Disaster Recovery into the project, DO NOT wait to come back to it later on. We are a 99.9% uptime world today, if you think otherwise...it's been nice knowing you

7. Launch quietly with your best. Unless there is some compelling need to do so, launch quietly, in parallell, and in person with your best group, team, region, etc. Full scale launch on day one is full scale disaster guaranteed.

8. What are your customers doing while you wait for your IT group to arrive to fix some problem? Plan for customer issues. Everyone seems to think of every issue that can go wrong, but never considers what your customer is doing while your employees are running around half insane! Don't surprise your customers above all else. Ensure all your managers are present that day and their only job is to greet customers. Ensure your Senior Management are in synch too so that everyone is focused. So many fail to see this one coming, but then wonder where the customers are going!

9. Launch - Designate a back offce team to be the temporary point of contact/help desk. This "crisis team" is specific to the launch only....leaving your Help Desk free to deal with the usual problems too...not just the launch issues. Begin transitioning support back to the Help Desk as the implementation issues ease in the days ahead. Amazingly simple and VERY effective if done correctly!”

MüTō Observation:

When I read the list you provided I noted that for the most part they typically assume a certain higher level of competence in PM's than other challenges I have been reading. For example; In order to 'hold Proof of Concept testing' or 'launch quietly' a PM would have to be able to hold his suppliers/testers accountable to support his aims, AND support a given corporate process. This will require skills in the PM that likely only come with experience, or specific training.

Ever meet a PM that follows the 'book' to the letter, without pause, or change, but fails anyway when faced with that dynamic project? Or perhaps a PM that fails to charge up his team, then wonders why they won't provide answers, support, when needed? Or maybe that PM that says "But they should be doing it...its their job." not realizing that people do not work because they have jobs, they have their priorities, and the PM has failed to make his, their utmost concern?

Any of the PM's I labeled above would not have a chance at tackling the issues you listed. So you are definitely talking about advanced topics.