Project Management is defined as the "organising and directing of other people to achieve a planned result within a predetermined schedule and budget"(Satzinger et al 2000). Most industries these days are project based, most of which involve information systems development. Developing a new system normally requires four major groupings of activities: Planning, Analysis, Design and Implementation. The planning phase is associated with the organisation and development of the project plan. The analysis, design and implementation phases focus on executing the project plan, monitoring and controlling, updating/modifying, communicating, and transitioning from development to production.

The planning phase is the building block for project management. If a project manager fails to plan, then he should plan to fail!!

1. Defining the business need and scope:
• What business need or problem are you trying to solve?
• Who will use / benefit from the solution?
• Key personnel should be identified and included early in the process. "If you involve the people who will be impacted, you will have better results" (Newby 2000)
• The output of a successful scopeing exercise is a document confirming that there is a need for the project deliverables and describing, in broad terms: the deliverables, means of creating the deliverables, costs of creating and implementing the deliverables, and benefits to be obtained by implementing these deliverables.
2. Demonstrating the project feasibility:
• Economic feasibility: Compare the estimated project cost to the presumed benefits.
• Calculate the ROI for the entire project life cycle.
• Organisational and Cultural Feasibility: Each organisation has its own culture, and one must determine if the new system will fit into the culture. Substantial changes to the functional or operational areas of an organisation require careful consideration.
• Technological Feasibility: Determining the available technology, the organisations in-house expertise, and the need to hire external expertise.
• Schedule and Resource Feasibility: Determining if the project can be completed on time. Determining the risks associated with not meeting the desired schedule. Checking the availability of resources (staff, equipment and physical facilities) as well as the level of the staffs experience and expertise.
1. Developing a schedule of project activities:
• Define the sequence of project activities
• Generate an activities list which in turn can be broken into various plan stages.
• Basically, the total work of the project is broken down into major subtasks. It starts with the end objective required and successively subdivides it into manageable components in terms of size and complexity.
• Microsoft project, or other such management tools are used to lay out the plan.
• The project plan should also include a formal communication management plan that documents descriptions and schedules of all information that is to be distributed or collected, and when this is to be done.
• Its recommended that project "vital signs" (monitoring points, used to determine if the project is running on schedule) be agreed upon by the project manager and sponsor at the beginning of the project and monitored throughout. Examples of vital signs are planned v actual budget, and planned v actual resources.
• Project schedules should be realistic
1. Organising and acquiring staff:
• Develop a resource plan for the project which should identify the required technical and professional skill sets, and level of commitment for both IT and end – user staff.
• The project manager is responsible for aquiring the best people and assuring that their time is dedicated to the project.
• A resource plan should describe how/when consultants are to be obtained if deemed necessary.
• Resource plan should document the roles and responsibilities assigned to each staff member.
• Staff members should be organised into working groups responsible for various tasks. Each group has to have a group leader responsible for coordinating tasks assigned to the group
• Project managers need to use and blend effectively the different personalities and behaviour styles of the project team members. How well project managers address this can make the difference between success and failure.

Project plans are not set in stone. Project managers should continuously re-analyse and modify the plan as needed.

 

 

Analysis Phase:

The analysis stage is associated with understanding and documenting the business and the processing requirements of the new system in greater detail. The project activities and tasks corresponding to the analysis phase are defined in the project plan during the planning phase.

The selection of the appropriate methodologies, models, and techniques required to effectively and efficiently perform the activities associated with analysis phases, as well as the design and implementation phases are also incorporated in the project plan during the planning phase.

Primary activities that are considered part of the analysis phase:

• Gather business requirements
• Design system functionality and requirements
• Build prototypes for the validation of requirements by end-users
• Prioritise system requirements and associated deliverables
• Develop and evaluate system alternatives
• Review systems recommendations with sponsors

Design Phase:

The design phase is associated with designing the system solution. The various activities deal with developing an architectural structure for software programs, databases, user interfaces, and the operating environment.

Primary activities that are considered part of the design phase:

• Design network interfaces and platform connectivity
• Design application architecture, database, and system feeds
• Design user interfaces
• Prototype for design details and end user validation
• Design system controls

Implementation Phase:

The implementation phase is associated with building the final system, testing it, and transitioning the system from the developmental version to the production version. The objective of this phase is not only to have a reliable, working information system but also to ensure that the users are all trained and that the business is benefiting.

Primary activities that are considered part of the implementation phase:

• Complete construction of all system components
• Verify and test final prototype of the new system(important to emphasise end user participation)
• Convert existing data to new system
• Transition new system into production
• Train end-users
• Hand off new system

Finally, throughout the execution of the project plan, periodic progress reports should be generated and shared with the project team. Project managers should consistently emphasise and bring attention to the project deliverables and deadlines, and communicate a sense of urgency to the project team effectively.

 

Some classic mistakes in project management

• Abandoning planning under pressure: Projects make plans and then routinely abandon them (without replanning) when they run into schedule trouble. Without a coherent plan, projects tend to fall into a chaotic code-and-fix mode, which is probably the least effective development approach for all but the smallest projects.
• Shortchanging upstream activities: Projects that are in a hurry try to cut out nonessential activities, and since requirements analysis, architecture and design don’t directly produce code, they are easy targets for the schedule axe. However, projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it earlier.
• Shortchanging quality assurance to improve development speed: Projects that are in a hurry often cut corners by eliminating reviews, test-planning, and all but most perfunctory testing. This is a particularly unfortunate decision. Short-cutting a day of QA activity early in the project is likely to add 3 to 10 days of unnecessary activity downstream.
• Lack of feature creep control: The average project experiences about a 25% change in requirements from "requirements complete" to first release. That 25% change in requirements produces at least a 25% addition to the software schedule . Many projects lack formal change control processes that could help them limit changes to those that are absolutely necessary.
• Wasting time at the front end: The front end of the project is the time before the project starts, the time normally spent in the approval and budgeting process. Its easier, cheaper and less risky to shave a few weeks or more off the front end than it is to compress a development schedule by the same amount. However, its not uncommon for a project to spend months or years in the front end and than to burst out of the starting gates with an aggressive often unattainable schedule.
• Insufficient user input: The number one reason that IT projects succeed is because of end-user involvement. Projects without early end-user involvement increase the risk of misunderstanding the project’s requirements and are especially vulnerable to time consuming requirements creep.
• Overly aggressive schedules: In 1994 the Standish group found that the average IT project took about 220% of its planned schedule. Scheduling errors of this magnitude set a project up for failure. Overly aggressive schedules also put excessive schedule pressure on developers, which ultimately hurts both morale and productivity.
• Adding developers to a late project: Adding developers to a project that is behind schedule is a common mistake. When a project is behind schedule , new people subtract more productivity from existing staff than they add through their own work.

How to spot impending doom:

• Benchmark goals are not met
• Unresolved issues outnumber deliverables
• Communication break down within project team and with customers
• Project costs escalate

 

When to call it quits:

• When costs exceed business benefits
• When deadlines continue to be missed
• When technology and/or business needs evolve beyond the projects scope