This is a multi-part article about common project management pitfalls.
Why is it that for most IT Projects, it is often difficult to meet the projected datelines, and deliver the system within time, budget and specification constraits? Indeed, as any project manager who is worth their weight in salt can testify, IT projects seldom, if ever meets the dateline, budge and specification. In fact, a study by the Standish Group Report (1995) shows that some 83.8% of projects are either challenged (the project is completed, but over-budgeted, over time-estimated or offers fewer features and functions than originally specified) or impaired (the project is canceled at some point during the development cycle). This has lead many project managers to dispair when things failed to go their way. What are the common causes of this problem?
Project objectives not fully specified / Poor Communications
Surprisingly, a study by Pete Marwick (1998) found that 51% of projects planning fails because the project objectives is not fully specified and poor communication between the client and the system analyst. There are many reasons why the project objectives are not fully specified or well-detailed. Below list some of the common pitfalls that lead to project failure under this catergory.
- Lack of Project Methodology to plan the deliverables
Project Methodology refers to the way in which the project is done. Most software development projects follow a project life cycle - the collection of project phases. A Software Development Life Cycle is a framework for describing the phases involved in developing and maintaining information systems. It provides a consistent and effective approach for undertaking projects. Without a clear Project Methodology or Software Development Life Cycle, it is difficult to impossible to plan for a job.
A clear framework or Software Development Life Cycle model to follow makes it easy for programmers and IT consultants to understand the job scope, and what the deliverables are at each stage. For instance, at the Requirements Specification phases in the waterfall model, the deliverables are all the requirements of the system, sample user interfaces, and the flow of events (sequence diagrams, event diagrams or flowcharts). With a clearly defined project objectives signed by both parties, it makes it easier to agree on the project objectives. Without doubt, one of the first objective of any solid project management plan is to plan for and agree on the project requirements. - Analyst failed to understand client's requirements and understand client's needs.
It is my opinion that the planning and agreeing on the project requirements phases is the most important part of the project life cycle. Finding out why the client wants a system, what type of system he is looking for, what type of software/hardware he needs is one of the most critical stages in the software development phases. By understanding the needs of your clients and putting it in writing, you can constantly review if the design of the UI meets their needs. Gathering information such as samples of previous work, documentations, interviews, surveys and other information prior to starting the work is essential to confirm what you will be doing, and scope of the project. Many project manager failed to see this as the most important part of the project, and allocated too little time to this phase. How are you going to plan and propose an effective system for your clients if you do not understand what is required?
Do allow at least 1 week to ensure that you understand all the documentations and process involved in the system, and the job scope. Only and only then can you begin to plan how long the project will take.
One good way of ensuring that you understand your client's business process is to draft a flowchart of the sequence of diagrams for each process. By doing so, you are confirming what you think is the way the process work against what the process actually work. Most clients happily point out your mistakes, so present your findings and ask them to clarify any doubtful points. Once there are no more obstacles, get your client to sign the documentation confirming that is the actual flow of events. - User Design is not what the clients wants...
Once the scope of project is confirmed, the next most important item is to draft the user interface. Those who just jump straight into programming without a drafting the user interface is in for a lot of re-coding work - especially when your user interface is flatly rejected by the client later on. Your user interface speaks volume of what you think what the clients want and need against what he actually needs. By providing a good user interface, both of you are agreeing on the scope of the work, and how the data should be presented. The client should sign off the user interfaces to show that he accepted the UI design. - Failure to check with client the actual data stored
The next most essential phase of the project is the design phases. Before you go on to conduct class diagrams, sequence diagrams etc, the first thing you need to do is to design the database first. The database should take in account all fields in the UI design. The primary key, a description of key flags (e.g. status: p = pending, c = completed, a = approved, r= rejected), and any foreign keys should be identified. Each table should have a short description of what information it stores. Finally relationship diagram should be drawn for easy referencing. By confirming with your client what type data are actually stored and can be retrieved, it helps to prevent problems later on, especially when they need some more data that is not stored (believe me, this is darn common). - Planning the Project Timeline.
Once all documentations above has been signed off, only and only then can the project datelines, deliverables and budget be planned and controlled with any good chance of completing the project on time and on budget, with all features and functions as initially specified. A common mistake many new project manager makes is to break down the work structure accordingly to phases in the Software Development Lifecycle. While this provides a good overview of what is to be done, it is at best, fairly inaccurate. The project manager should instead further breakdown the work into sections, and allow some time for each sections. For instance, the work involved requires some 30 User Interfaces screen. Planning 1-2 days for each UI for a 3 tier development for each staff assigned helps to paint a more accurate picture of the time required for documentation and programming.
The client should be informed of the project plan and sign off the agreement on datelines of the project. Also, it is a good communication practice to inform and update the client on project progress status on a weekly basis.
- Documentation and Designing the Sequences Diagram, Class Diagram, Event Diagrams
At this point, the next key step is to draft all the documentation. The sequence diagram, class diagram and event diagrams should be planned and documented prior to coding. By documenting how each class is related to one another, and planning for a 3 tier architecture, you are ensuring reusibility of class, and saving time on programming. Also, by doing this, you are insuring yourself against changes in business logic or database structure. When such change are required, they can be implemented with minimum effort by identifying which classes are affected by the changes.
Many programmers hate this step and in some companies, this step is often left until all the programming has been done. - Frequent changes to the project specification
Let's face it, the client is human too, and human has a tendency to change their mind. The worse clients are those who have no clue to what they want and frequently change their mind - because once the system is coded and development is under way, the system is often inflexible and the changes to the coding or database are often tedious and time-consuming. This is especially so when a small change in code or database can lead to all sorts of bugs can pop out elsewhere in the program, and tons of re-editing the documentations is required. By getting the work flow, user interface and database signed off, you are protecting yourself against any changes to project specifications.
Should your client insist on the changes after all the specifications have been signed off - it is best to evaluate if the change can be implemented with minimum inconvenience. This is where all the documentations come in handy - review the documentation to see if the changes will affect several classes or isolated to one or two classes. If the changes can be implemented with minimum effort, it should be incorporated into the system - building a good relationship with a client is important. However, if the changes required is medium to heavy in effort, it is often required to politely but firmly inform the client that these changes are not in the requirements, as per the signed off UI, database and project plan, but you can implement them for an added fee - it is not good business to engage in a losing preposition. Also, there will be a delay in schedule to accommodate the changes required. Often the increase in budget and delay in delivering the system will make the client think twice if the changes to be implemented are essential or just a whim on his side. Even if the changes is to be incorporated into the system, there is some benefit for your organization in terms of increased timeline and profits.
Posts
No comments:
Post a Comment