Project Management

The checklist describes why the IT system project is a victim and how to turn around a failing project. Experience shows that most of the system projects become victims of failure for the following reasons:

• The system development team did not understand the requirements of the customers, stakeholders, and users.
• The scope of the project is not well defined.
• The chosen software and hardware technology changes.
• The project lacks senior management support and commitment.
• The return on investment (ROI) is not realistic.
• The schedule for completing the project is not real.
• The users are resistant because of proprietorship of assets.
• The project lacks professionals with appropriate skills.
• The project lacks cooperation and enthusiasm among the practitioners.

Personal Characteristics

• Is technically qualified
• Is a decision maker
• Is honest and creates a relaxed atmosphere
• Possesses the art of saying no without offending others
• Believes in managing time and people.

Project-Related Characteristics

• Achieves the objectives and goals of the project within the established schedule, budget, and procedures
• Develops IT projects on budget and on time to the complete satisfaction of the users
• Has experience in related or similar projects
• Can control project outcomes by measuring and evaluating performance against established objectives and standards

Requirement elicitation is a process performed by analysts who gather and understand information. This process involves the following factors:

Fact-finding. Fact-finding uses mechanisms such as interviews, questionnaires, and observation of the operational environment of which the system will become a part.

Validating the customers understanding of the gathered information. Validation involves creating a representation of elicitation results in a form that will focus attention on open issues that can be reviewed by those who provided the information. Possible representations include summary documents, usage scenarios, prototypes, and graphic models. A requirement proposal, requirement communication, and requirement definition achieve requirement elicitation. A requirement proposal outlines the need for customer requirements.

1. Functional gaps open up
You review a system that meets most of your requirements and rates well against competitors. Should you acquire it?

Most product evaluation methodologies only evaluate the fit of the current product against current business requirements. An underlying risk when acquiring technology products is that the successor product may be less well aligned with emerging business requirements. This has most to do with the vendor’s capability and product development track record but is unfortunately often overlooked when an out-of-the-box solution appears to offer a fast track to the desired (short-term) solution goal.

Over time as functional gaps open up, greater effort needs to be ploughed into modifying or working around the solution. The paradox is that with every modification you further commit to the increasingly ill-fitting system.

2. Aggressive upgrade cycles
When you are changing software because your vendor has released a new version (and withdrawn an old one) and not because you perceive any great advantage from moving, you are in the upgrade cycle. When you are changing hardware because your new software won’t run on the old hardware, you are in the upgrade cycle.

Here is some of the IT project risk factor that could be happen in your IT project.

Project size – a big project is a risk factor – variously measured in terms of how ‘big’ the delivered solution is to be (say, measured in terms of functionality) or how many resources are being allocated to complete the planned tasks;

Organization impact – a big organization impact is a risk factor – typically from a user base and business process perspective; for example, a whole-oforganization user base application that reshapes multiple core business process is described with a higher risk factor than say a local user base application that addresses only a single, non-core business process;

Project complexity measured from the perspective of its dependencies with other projects – more dependencies is a risk factor; number and types of technologies being used – more technologies is a risk factor; amount of customization being undertaken – more customization is a risk factor;

Although this is not a step in the SDLC, an organization might decide to buy a product instead of building it. The decision typically comes down to time, cost, and availability of a predesigned substitute.

Before moving forward with the option to buy, the project team should develop a request for proposal (RFP) to solicit bids from vendors. Vendor responses should be closely examined to find the vendor that best meets the project team’s requirements. Some of the questions that should be asked include these:
. Does the vendor have a software product that will work as is?
. Will the vendor have to modify the software product to meet our needs?
. Will the vendor have to create a new, nonexistent software product for us?