Executive Summary
The summary has captured most of the important details, which are covered in the plan. A reader who does not have enough time to read through the whole document can at least get a good idea of what the document talks about, even without reading the whole document.
The purpose of the report together with the major findings is clearly outlined, but the recommendation is omitted. In addition, most of the information which is written here is repeated in the introduction. The summary has been written in its own page such that the plan looks organised and easy to follow.
Introduction
The introduction is written in a concise manner, and it has at least met the primary objective. It has clearly indicated the scope of the report, and discussed the objectives in an easy and understandable language. Generally, the introduction has provided a good summary of what will follow.
Name
Although the name reflects the nature of the project, it is not the best to choose. This is because it is not easy to understand its meaning, as it is too long and somewhat ambiguous.
Perhaps, it could have been shorted, and words which are not easily confused used instead. Again, terminology scares those who do not understand IT. In other words, despite its importance, the name is a little bit too complex for a lay man (Schwalbe, 2006).
Description
This section has been used to give details of the project description. It has captured information related to goals and the purpose of the project. Although the language used is a little bit complex, someone who understands project management’s basics can hardly fail to understand it. Most evidently missing from this section is a time and cost estimates (Robert, 2009).
Sponsor’s details
This section has incorporated a discussion of all the critical details relating to the sponsor. The names, title, and the contact information has been provided. If it becomes hard to contact the person whose details are given, then one can contact another person whose contacts have been provided as back-up.
Project manager and team details
The project manager and the team’s contacts have been provided. Their names, titles, and contacts information are available. In addition, back-up contacts have been provided in case any official is not easily reached.
Deliverables
This section has been used to discuss the project’s deliverables. The author has listed all the products together with their description. However, the author has not separated them according to their related categories. This makes it hard to understand their relationships.
Reference details
This section has revealed all the references that have been sourced from different field, including project management, information technology, procurement management plan, and quality management plan. In addition, a list of the sources that were used has been included, however, it has not been properly formatted according to APA writing style – it contains numerous errors of style.
Definitions
This section has been used to throw light on the most technical words. However, the author has overlooked many words, which are not easily understood by a reader without specialised knowledge in particular field such as IT. Only a few technical words have been defined in this section. The language that has been used for definition is easy to understand (Sebastian, 2007).
Organisation
Organisational charts
All the organisational charts that have been used are explained in this section. The author has used simple diagrams, which make it easy to understand the structure, including the lines of authority.
The roles and names have also been clearly provided. One can easily understand different representatives and their line of authority. All the charts have been included and a proper evaluation undertaken – the section is excellently done (Marchewka, 2006).
Project responsibilities
A review of all roles and responsibilities in the project has been tackled here. An example of such review includes responsibility assignment matrix (RAM), which has incorporated all the responsibilities together with those who are responsible in carrying out the tasks.
This matrix has clearly described different responsibilities which are awarded to different members. For example, it is easy to understand the project team leader’s role, and that of any other member.
Management And Technical Processes
Management objectives
This section has provided a precise description of the managerial objectives. The objectives are very realistic since the manner in which they could be achieved is disclosed, while at the same time paying attention to the constraints of the project.
The assumptions that are set by the management have also been outlined. However, this section does not make it very clear, how the management intends to monitor the process of the project to ensure that all the objectives are achievable.
Project controls
Change control procedures and project monitoring strategies are described in this section. The management uses quarterly reviews to monitor the progress of the project and to ensure that the objectives are met. The monitoring strategies described in this section are comprehensive and easy to understand.
There is a clear indication of factors that could cause problems to the project, and possible ways of avoiding them proposed. The information system control system has also been well described, though the amount of terminology used to explain how it works may be hard to be understood by a person without technical knowledge in IT.
Risk management
This section has clearly outlined the way the project team will manage, identify and control risks. There is a comprehensive description of the tools that will be used to identify and control risks. The tools, which includes impact matrix, have been provided in the appendices section. The explanation of such tools is precise, and in simple language.
Project staffing
Appraisal of the staffing plan has been provided in this section. The number and the type of staff required is clearly indicated, though the rationale is missing.
The roles and responsibilities are well described in tabular indexes. Some critical diagrams, which could make it easier to understand the staff requirements, are absent. For example, a resource histogram has not been provided.
Technical processes
The documentation standards are described in this section. The language used is simple and clear, making description of the standards very easy to understand. The system development lifecycle has also been discussed in this section.
A simple structure is used to describe the cycle, which is well numbers and extensively explained. Nevertheless, some terminology is not well defined; hence, it is not easily understood by a person with no technical knowledge. The justification is clearly provided. In regards to this project, the choice of the approach seems appropriate.
Work To Be Done
Major work packages
The organisation of the project has been outlined well in this section. It makes it easier for a reader to have a general knowledge on how the project is organised. The author has described the structure in a comprehensive manner, and clearly indicated the scope of the project. Different tasks have been broken down and categorised according to their relationships.
Key deliverables
This section has been used to discuss the project’s deliverables. The author has listed all the products together with their description. However, the author has not separated them according to their related categories. This makes it hard to understand their relationships.
Other
This section has reviewed other critical component of the project, including the software and hardware requirement. Important details relating to software such as compatibility and security have been discussed. Hardware requirements, such as compatibility, acquisition and security have also been discussed here. However, the assumptions have not been provided.
Schedule
Summary
The overall project schedule is provided in this section. Milestone report and Gantt charts are also discussed in this section.
Detailed
This section has provided a judgement in regards to the information contained in the schedule. Relationships between network diagrams and project activities are provided. Generally, description in this section is relatively accurate and well reported.
Other
The assumptions related to the project schedule are stated well, however, they do not seem to be exhausted.
Budget
Summary
This section has provided a detailed report in regards to the estimate of the budget. The aim of the budget is to show all the budget line items and reflect the figures in present terms among others.
Detailed
The project budget and other project cost management plan have been accurately provided. The figures are accurately represented and the plans are realistic.
Other
The information related to financial aspects, such as assumptions, valuation methods, budget constraints, source of finance, and methods of filling budget gaps are provided here. They are discussed extensively and in a simple language.
Conclusion
The use of planning tools in IT projects is one way of ensuring that there is efficiency in achieving the project’s goal. Despite having these tools to improve the processes, procedures and outcomes of many IT projects, the application of such tools is not a major guarantee to successful planning and execution of projects. Several reasons may lead to unsuccessful development of IT projects while using these planning tools
The planning tools of IT projects are organized in a manner that enables the IT professional experts to achieve the intended goal(s) of their projects with great effectiveness. The planning tools for IT projects tend to be organized to fit different project planning components.
That is to say, the planning tools are organized to help IT planners in the areas of determining the scope of a project, its specific activity and overall duration as well as costs (Kerzner, 2003). This project management plan is generally well organised, though there are some critical areas that need improvement, so that it can be more effective.
As already highlighted, a project name is very critical, and should be designed in a simple manner, which is easy to memorise and understand. It has been stressed that the project name should be related to the nature of the projects. In this regard, the name chosen in this project should be restructured.
The goals and objectives of the project are also very critical. Throughout the report, it has been emphasised that the goals should be clearly stated, and should be realistic. Generally, this plan has outlined its goals and objectives in a precise and realistic manner.
The other area which has been very important in determining the effectiveness of this plan is in regards to the language being used. It is evident that the language used to describe different sections of the plan should be easily understood, even by a person without a particular technical knowledge.
A major weakness that has been pointed out in this project plan is in regards to the use of terminologies without proper definition, which locks out people who do not understand that particular language from effectively using the plan (Patel, 2000).
Different tools that are used in the project plan are very important, and should be described very clearly and extensively. For example, Gantt charts, responsibility assignment matrix, organisational chart diagrams and any other tool have been used in this plan to explain different concepts.
As discussed, such tools should be easy to follow and understand. No important tool should be left out in a project plan. For instance, the Gantt charts are used to direct and assist the IT project developers during the planning stage of the project development.
The PERT charts are also other useful tools which are used at the planning stage. However, although these planning tools are set to contain specific information and data for the project development, the data or information contained in one particular planning tool is useful for development using other planning tools.
As revealed, the tools used in the planning are mostly organized on project’s major framework. Even though they are set on certain categories, the procedural application is not quite clearly defined for easy application by novice IT project planners.
Frankly speaking, the planning tools appear to be designed to pass messages mainly through use of visual representation. Heavy use of visualization items is likely to cause message misinterpretation and barrier to tools applications in developing excellent project plans.
Without proper and keen study of the graphic tools, it will be very hard and difficult for a user to apply some of the tools effectively, including the Gantt charts. Where certain tools are disconnected, like when using excel to make certain calculations, it poses high chances of having certain planning stages omitted or getting missed (Wysocki, 2007).
The current planning tools in IT projects are depicted to be advanced in terms of technology use. This advancement of planning tools has helped many experts in the development of excellent IT projects with a great ease than it was with manual project planning.
Despite these advantages of having advanced technology use in the planning of IT projects, there are overt limitations and disadvantage associated with these planning tools (Albert, 2004).
To further improve the effectiveness in project planning, it is necessary to improve communication through incorporation of messages which are clear. In short, there is a need to automate the tools by including more detail in the planning tools and inclusion of an electronic trainer in the application of the tools that would show orderly application of tools.
References
Albert, H. (2004). Handbook of Project Management Procedures. New York: TTL Publishing Ltd.
Patel, P. L. (2000). The project manager’s desk reference: a comprehensive guide to project planning, scheduling, evaluation, and systems. New York: SAGE.
Kerzner, H. (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (8th Ed. ed.). London: Wiley.
Marchewka, J.T. (2006). Information Technology Project Management, (2nd Ed.). Danvers, MA: John Wiley & Sons.
Robert, T. (2009). Project Plans: 10 Essential Elements. London: Project Smart.co.uk.
Schwalbe, K. (2006). Information technology project management, (4th Ed.). Cambridge, MA: Course Technology.
Sebastian, N. (2007). The Definitive Guide to Project Management. (2nd Ed). London: Financial Times / Prentice Hall.