The Ten Commandments of Successful IT Project Management

Even with the best of intentions, managing projects in the Information Technology arena will always include elements of chaos. As a Project Manager you have a responsibility to effectively manage your project in a way that meets customer and stakeholder expectations.

Managing the expectations of your customers and stakeholders is just as important as understanding the vision and expectations of the initiative. Because you most likely do not have control over many of your resources, Stakeholders, Customers and Sponsor – identified process is the way in which you can successfully manage technical projects.

Identified process and communication of identified process will provide the parameters, expectations and the governance you need to be successful. In my experiences, failed projects all have had the same common thread; there was either a lack of defined process or identified processes were not properly communicated and adhered to. The good news is defined project management processes are available and made to be leveraged. The Project Management Institute (PMI) and Capability Maturity Model Integrated (CMMI) offer best of breed industry standard process in both Project and Organizational Management.

A project is defined as is a temporary endeavor with a defined beginning and end and often constrained by funding or deliverables. The following ten principles are essential and must be utilized for your project to succeed.

1) Sponsor / Business Commitment.

The Project Sponsor has the most interest in the project; in most cases the project is fulfilling business needs for the sponsor. Therefore, the Project Manager and Project Sponsor have a partnership and shared interest in the success of the project. In addition, the Project Sponsor usually controls resources and works directly with or supports the Project Stakeholders. Usually Project Sponsors are not understanding of the level of detail and commitment needed to successfully manage a technical project. The Project Sponsor must be engaged and fully understanding of the project scope and approach. In as much as the Project Sponsor needs to understand your commitment and approach, you need to understand the Project Sponsors commitment and expectations. Through the Project Sponsor, the business group must also have a clear understanding of their needed commitment and project approach. If the program does not understand and has not allocated time needed for their tasks, the project will most likely be delayed. A knowledgeable business team member will be required in many of the project phases including: analysis, JAD sessions, planning, design and testing.

2) Stakeholder Identification.

All stakeholders meaning all people affected by the project and or initiative must be identified. This is critical. Even successful projects can be a disaster if the initiatives are not understood at an enterprise level.

3) Project Scope.

It is critical that every project have a clearly defined scope that details all deliverables in relation to the business needs being met. The scope will be agreed on by the sponsor and all stakeholders, including Project Team Members. Any changes to the project scope will be addressed through the change management plan (discussed later).

4) Project Requirements.

Every project will need identified project requirements; the level of detail will depend on the complexity of the project. Generally, project requirements consist of functional (business) and technical requirements. The functional requirements address the business needs and may include: use cases, process flow diagrams, data needs, reporting needs, gap analysis, testing requirements and other documentation that accurately identifies the business needs. Technical requirements leverage the functional requirements with consideration to any technical standards and policies of the organization. Technical requirements may include: data base diagrams, architectural diagrams, screen shots, performance requirements and other technical specification and design documents needed to procure or develop the desired solution. It is understood that requirements are developed through analysis which will include Joint Application Design (JAD) sessions as well as interviews and or review of existing documentation. Both functional and technical requirements are to be reviewed, understood and approved by the designated project management Team.

5) Detailed Project Plan.

Contrary to popular belief a project plan is not just a Microsoft Project gantt chart/mpp file. A true project plan will consist of the following documents:

• Project scope – defined above

• Project requirements – Defined above

• Communications plan – A Communications Plan will identify all stakeholders who will receive communications, the level of communication, the method of communication and how often. This is important to set the expectation of how your stakeholders will be communicated with.

• Risk management – this document will qualify and quantify risks and how they will be mitigated.

• Gantt chart/project/cost schedule. This document; commonly referred to as the project plan will include time estimates, dependencies, milestones and identified resources. The gant chart includes the scheduling, dependencies and resources needed. This is the document that will be referred to when managing the schedule.

• Issues list/ action items. As issues are identified they will be included in the issues list, assessed and prioritized. The project team will determine how the issues will be addressed.

• Change Management Plan – The process in which scope change will be handled (described below)

6) Change Management Plan.

A change management plan identifies the processes involved when a requested change affects the project scope, requirements and or schedule. Typically the requested change, resolution, needed resources and project impact is identified by the project team. The final decision on how the request is handled is usually provided by the Project Sponsor and or Stakeholders.

7) Project Baseline

It is recommended the project be saved to a baseline. The baseline identifies the schedule and saves it. Any deviations from the base-lined schedule shall be identified and reported as part of status reporting.

8) Project Monitoring and Reporting.

Status reporting shall be done on an identified basis (determined in the communications plan) and include statuses regarding the schedule, cost, resources and any other issue which impact the project. In most cases an Issues list is employed to track identified issues and how the issues will be resolved in the form of a stated action.

9) Exception Management.

In as much as we would like things to go according to schedule, they rarely do. Exception management is a must and includes all actions relative to managing project exceptions. Exceptions include, project variances, schedule variances, scope change, resource issues, personnel issues, personality issues and any other issues you can think of.

10) Needed Skill Sets

To be most effective a Technical Project Manager should have a thorough understanding of: project management process, technical knowledge, and organization and communication skills.

Project Management is as dynamic and rewarding as it can be gut-wrenching; my advice- expect both. I hope this article provides assistance and a realistic reference for you to be most successful managing your projects.

This entry was posted in Uncategorized. Bookmark the permalink.