IT Project Management Approaches - Report Example

?IT Project Management Approaches Project management is not a new field as it has been in existence forquite some time now. All projects be it Business, or IT have to follow a given approach whether consciously or unconsciously. People and resources have to be managed effectively so as to produce desired outcomes. In the same light therefore there exist project management approaches that include agile, iterative, incremental and phased approaches. This paper discusses two approaches that is the traditional/phased approach and the agile approach to IT project management, by describing and analysing them from different perspectives. It narrows down from the above two and looks at some of the specific applications in the information Technology field by looking at the Software development life cycle approach that is part of the traditional approach. It goes further in the agile approach to look at specific applications of the approach to the field of information technology. The paper also compares the two approaches by looking at their strengths and weaknesses and the type of projects to which they can be used/ applied and why they will or will not work. 1. The traditional/phased approach to project management The traditional approach to project management involves very well-organized and deliberate planning and control methods. In this approach there are distinct project life cycle stages or phases which are easily recognizable as one leads directly to another. Tasks are completed in in an orderly sequence, one after the other and this necessitates that a significant part of the entire project is planned before the process begins (Hass, 2007,pp1-8). This model assumes that all events affecting the entire project are predictable and that the tools and the tasks undertaken by each individual are well understood. With this approach it assumes that once a phase is complete it will not be revisited, which is not the case for many projects especially IT projects. This model is forms the basis for the phased methodology used in many projects. The approach has taken many dimensions especially in the field of information technology with various sub models coming up from this traditional/phased model (Hass, 2007,pp1-8). The advantage of this approach is that it sets out the phases for development and stresses the importance of requirements for each stage. On the other hand the limitation is that projects rarely follow the sequential flow and many stakeholders find it difficult to define all the requirements for a project at the beginning(Hass, 2007,pp1-8). The approach has the following distinct stages: initiation, planning and design, execution and construction, monitoring and controlling systems and finally the completion stage. It is important to note that not all projects will go through all the stages mentioned above some may be terminated before they get to the completion stage. 1.1. The Software Development Life Cycle (SDLC) In information technology projects, this phased approach can be compared to the software development life cycle approach (SDLC). This approach is composed of the following distinct stages that must be followed to come up with working software: planning, requirements definition, design, development, integration and testing and finally installation and acceptance (Radack, 2009, pp1-7). The planning stage aims at establishing a bird’s eye view of the proposed software product and uses this to form the basic project organization, assess feasibility and risks associated with the project and define suitable management and technical approaches. The most critical part concerning this stage is the listing of goals of the project and this is done before anything else (Radack, 2009, pp1-7). The requirement definition stage begins immediately the goals in the planning stage are identified. Each of these goals is then refined into a set of requirements which define the major functions of the proposed application and also define the initial data entities. The major functions include: the critical processes to be managed, mission critical inputs outputs and reports. Each of the definitions are known as requirements and are identified by distinct requirement identifiers that contain at minimum a requirement title and a textual description (Radack, 2009, pp1-7). The design stage follows next taking input from the requirements identified above. For each requirement a set of design elements are produced and these are as a result of interviews and workshop efforts. This section describes the desired software features in detail. Two documents exist here, the software design document that contains the design elements and such as process diagrams and the second document called the physical database description that contains structural design elements such as data dictionary. These elements are necessary to provide sufficient information for the programmers to develop the software (Radack, 2009, pp1-7). The development stage uses inputs from the design stage where for each of the design elements a set of artefacts are produced. The artefacts include menus, dialogs and forms among others. At this stage appropriate test cases are developed for each of the related functionality artefacts and an online system is also developed to act as a guide for users(Radack, 2009, pp1-7). The integration and test stage the artefacts, online help and test data are moved from the development environment to a test environment. Tests are then run to verify completeness and correctness of the software. The successful execution of the test suit confirms a robust and complete migration capability. Lastly the reference data is finalized for production use and the production users are identified and linked to their correct roles (Radack, 2009, pp1-7). The last stage is the installation and acceptance stage where acceptance tests are carried out to verify the correctness and completeness of the product. Once it is verified and the suit executed with satisfactory results, the customer formally accepts the delivery of the software product. This method follows the essential components of the traditional approach in phases with one phase leading directly to the other. There is completely nothing that can be done in the following stage before the preceding stage is complete. This approach (the SDLC) is typical and must follow all the above stages for software to be complete (Hass, 2007,pp1-8). 2.0. Agile project management Approach Agile project management approach is a high iterative and incremental process where the developers and project sponsors work together to understand the domain, identify what items need to be created and prioritize functionality(Hass, 2007,pp1-8) . Agile approach is not a single method but a series of methods that are used in project management. The agile methods are used when the following conditions are present: the end user participates throughout the project; the customers, designers and developers are co-located; the aspect of incremental development is possible and visual documentation is possible. The agile approach is best suited for small scale projects. It differs from the traditional approach such that it is very flexible and project deliverables are submitted in stages without having to be defined at the commencement of the entire project. The agile approach is composed of many rapid iterative planning and development cycles that allow a project team to constantly assess the evolving product and obtain instantaneous feedback form customers and stakeholders. The team gets to learn and make improvements on the product along with their working methods from each consecutive cycle. After a streamlined planning, definition of requirements and the solution design phases are completed to get the project going, iterations or a repeat of more detailed planning, requirements, design, building and testing occurs in waves (Hass, 2007, pp1-8). This approach contrasts with the traditional approach as it requires a dedicated full time project team that includes a customer or end user of the product and members should work from the same location. The Traditional approach and especially the SDLC approach does not require team members to work form the same location. Team members can work from different locations and the end user of the product gets to test the product during the last stages of the product development (Hass, 2007, pp1-8). The customer does not necessarily have to be part of the project team u is located in a testing environment where the product will be tested after most of the work is complete to pave way for installation and acceptance. In a typical IT project the approach is used with a small co-located team. The team is usually composed of two developers who come up with codes in pairs; this is done for quality control purposes, the customer, IT architects, a business analysis and a project manager. The work is accomplished through a series of sessions where the team writes codes, then tests working modules of the system and the process is repeated again. There exists minimal documentation as mostly the team relies on informal internal communication (Hass, 2007, pp1-8). The agile processes include three major attributes and these include: (1) incremental and evolutionary where it allows the adaptation to both internal and external events; (2) modular and lean where it allows components of the process to come and go depending on the specific needs of the user and the stakeholders; (3) time based where it is built on iterative and synchronized work cycles, which contain feedback loops and progress checkpoints (Alleman, 2002, pp1-22). The above attributes translate into a series of behaviours that are typical for the agile project management approach. These behaviours include self-organization of teams of people less than nine, a guiding vision that is necessary for predicting change and adapting to different situations, simple rules that culminate into complex behaviours that are seen to emerge over time, free and open access to relevant information for the completion of the project, a light touch management style which is seen to replace the traditional control approaches and lastly adaptive leadership in order to balance on the edge of chaos (Tignor, 2009, pp1-23). The agile approach works in better in small projects and this one of its biggest let-downs as compared to the traditional approach that can be used to manage a project in various geographical locations. Secondly this approach uses customers in the process so as to tailor the product to their needs, this may not work when many customers are involved because of the complexity of needs that arise and this brings in the traditional approach that works better in such situations (Tignor, 2009, pp1-23). In conclusion Project management approaches depend on the type of project and the expected outcomes of the project. One method may work for a project while another may not. The two approaches discussed above present both positive and negative aspects in project management. Each one of them is different in its own light but can be adopted and suited for a specific project (CMS, 2008, 1-10). List of References Alleman, G. B. (2002). Agile project management methods for it projects. In E. G. Carayannis, & Y. H. Kwak, The Story of Managing Projects: A Global, Cross– Disciplinary Collection of Perspectives, (pp. 1-22). Colorado: Greenwood Press. CMS. (2008, March 27). Selecting a development Approach. Retrieved October 23, 2011, from Center for Medicare and Medicaid Services: https://www.cms.gov/SystemLifecycleFramework/downloads/SelectingDevelopmentApproach.pdf, pp1-10 Hass, K. B. (2007). The Blending of Traditional and Agile Project Management. The PM world Today Journal, IX(V):1-8. Radack, S. (2009, April). software development life cycle . Retrieved October 23, 2011, from National institute of standards and technology: http://csrc.nist.gov/publications/nistbul/april2009_system-development-life-cycle.pdf, pp1-7 Tignor, W. W. (2009). Agile Project Management. International Conference of the System Dynamics Society (pp. 1-23). Severna Park, MD: IEEE. Read More