IT Project Management Pitfalls…

http://www.devx.com/enterprise/Article/46472

Internet.com

Comments to:

9 IT Project Management Mistakes That Will Sink Your Project

Your article identifies some good points to ensure your project stays on track.

As I read the article and reviewed some of the comments I had several comments.

Eddie Williams Comments:

PM Pitfall #1. Inaccurate Scheduling

Planning and estimates must be realistic and accurate. But it is having the right/appropriate people participating and providing input that will achieve that goal.

PM Pitfall #4. Being Too Passive

Good leadership along with the required management skills is required by a project manager. Two reasons or factors that lead to project failure are poor or inadequate leadership and communication. Leaders influence and motivate others, set an example, direct and guide a team(s). Project managers must have good management and people skills. They must not just manage the activities and deliverables of the project life cycle. They must also manage teams; people. It is teams that ultimately accomplish the objectives of a project. Teams comprised of members getting the job done, involved and committed to the goals and objectives of the project/program and business.

To be in business just to make money is a narrow view of why you’re in business. Would that be the primary reason and focus? What does that say about your business purpose and mission? Are they directed toward the customer, the products and services you are providing to the market? The money (and profit) will come when you service the customer well. The statement should be…Do what the role calls for and take charge and manage the project and people through project close out.

I conclude the above comments with the following:

I recall several years back being a member of a business and professional network group. Several individuals made a strong statement, “I’m in it to make money”. I, not wanting to really debate at that time (but I did ask some questions, kept what they said in mind. Several years later I had two of these business owners and professionals approach and engaged me in conversation. They had recalled the questions I had asked. One of them stated, “Several years back I forgot what I was in business for and who my market and customers, consumers, and users were. I lost focus and my business and my people (employees) paid the price.”

Why learn a lesson the hard way. Know and understand why you are really in business. State it in you purpose and mission statements. Realize your vision. Achieve your goals, accomplish your objectives, meet or exceed your expectations and align your projects and program with your business plans and strategies – the money (and profits) will come.

PM Pitfall # 7. Allowing Scope Creep.

I won’t say much here accept set up and establish a change management process (with a configuration control process within) in the beginning of the project and ensure it is conducted throughout the project. It will address potential project changes, problems or discrepancies, and product/system configuration changes. Also include a process to expedite critical or time sensitive changes that require review and approval. Within that process you are controlling scope creep (considering scope of work and scope of requirements).

PM Pitfall # 8. Having No Pilot Phase.

I like here considering the importance of a pilot. I believe and encourage use of pilots, Proof of Concepts, prototypes and mock-ups and review and testing. Used and created/developed as required with the customers and users involvement and participation early and throughout the project.

General comments:

Build a core team that will have the appropriate skills sets, be involved committed and whose team members are empowered to do their jobs, meets the goals and achieve the objectives, and most importantly bring the project to a successful conclusion. Also acknowledge and recognize the team and members accomplishments and achievements.

There are no silver bullet methodologies, neither past nor present. But we have come a long way by improving development processes and methodologies. But each methodology has gaps depending on its application and can be improved (keep that in mind) and sometimes those gaps in using one or another methodology may mean that you may have to use activities of another to fill gaps. My experience has been just that, with successes throughout my career. Ensure that you are involved and that the customer (and users) is involved, participating and is commitment from the beginning and throughout the project.

Much of what you plan and execute/implement should not be unknown to the customer, users and others. If so, it is high risk. You want to consider not just time, but approved budget(s), performance and quality, and customer and user satisfaction. That has been the case for me and the teams built. After the lessons learned in the beginning of my career that has always been my take. It surely supports knowledge transfer.

Note: It is not micro management to ensure members are completing assignments; getting a daily status.