Presentation on theme: "Information Technology Project Management"— Presentation transcript:
1 Information Technology Project Management By Jack T. MarchewkaNorthern Illinois UniversityCopyright 2009 John Wiley & Sons, Inc. all rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the information contained herein.
2 The Nature of Information Technology Projects Chapter 1
3 IT and Modern Day Project Management 1940s1950s1960s1970s1980s1990s2000s2010sFirstElectronicComputerEDPEraPCEraNetworkEraGlobalization
4 IT and Modern Day Project Management EDP era began early 1960SPurchase of centralized mainframe by large organizationsIT projects focused on automating key organizational functions – accounting, inventory, production schedulingImprove efficiency and reduce costs of manual and clerical tasksStructured approach used for managing these projects as the requirements were stable and well understoodCreated information silosDP manager reported to head of accounting or financial manager
5 IT and Modern Day Project Management Micro era began early 1980sProliferation (sometimes uncontrolled) of PCs challenged centralized control that was in placeLed to user-developed, decentralized, independent systems that replicated data throughout the organization and vied for IT supportRole of CIO is created to ensure that IT is used strategicallyReported to CEO to show importance of the CIO position and critical role to be played by ITPCs needed to coexist and integrate with mainframesIT projects now crossed functional lines and requirements were changing at a faster paceSoftware development methodologies introduced to manage the less stable requirements and shorten the development life cycle
6 IT and Modern Day Project Management Network era began mid 1990s due to the advances and growth of the ARPANET /Internet.Projects focused on the challenge of creating an IT infrastructure to support many partners, strategic alliances, vendors and customers.Network architecture has to be scalable to support thousands of networked computers in a timely and efficient mannerDigital convergence of data, voice, graphics and video allowed for new and innovative ways to deliver new products and services to customersMicro era projects focused on creating an internal network within the organization, network era focused on extending the network externallySupport a dynamic business strategy and new organizational structuresIT project members need to understand the technology, but more importantly, the organization and its competitive environmentBenefits and risks much higher than the previous two eras
7 IT and Modern Day Project Management Globalization era – we’re in the beginning stages nowThomas Friedman “The World is Flat”The combination of technology and lowering of political barriers has flattened the world so that it is now possible for people and organizations to work with almost anyone in any place at any timeThe global competitive playing field has become level for everyoneSee his talk at MITProjects today are more dynamic, geographically dispersed, and ethnically or culturally diverse as ever beforeIT personnel require a solid set of technical, non-technical and project management skills based on past experience but adapted to this new environment
8 IntroductionInformation Technology (IT) projects are organizational investments that requireTimeMoneyAnd other resources such as people, technology, facilities, etc.Organizations expect some type of value in return for this investmentIT Project Management is a relatively new discipline that attempts to make IT projects more successful and combines traditional Project Management with Software Engineering/Management Information Systems
9 An ITPM ApproachOrganizational resources are limited, so organizations must choose among competing interests to fund specific projectsThis decision should be based on the value a competing project will provide to an organization
10 Which Situation is Worse? Successfully building and implementing a system that provides little or no value to the organization?Or…Failing to implement an information system that could have provided value to the organization, but was underdeveloped or poorly managed?
11 Modern Project Management Often credited to the U.S. Navy as an outgrowth of the Polaris Missile Project in the 1950’s.Focuses on reducing costs and product cycle time.Provides an important link between an organization’s strategy and the deployment of that strategy.Can have a direct impact on an organization’s bottom line and competitiveness.
12 Why Do IT Projects Fail?Larger projects have the lowest success rate and appear to be more risky than medium and smaller projectsTechnology, business models, and markets change too rapidly so projects that take more than a year can be obsolete before they are completedThe CHAOS studies also provides some insight as to the factors that influence project success
13 The Software CrisisThe CHAOS study published in 1995 by The Standish Group found that although the U.S spent over $250 billion on IT projects, approximately…31% were cancelled before completion53% were completed but over budget, over schedule, & did not meet original specificationsFor mid-size companies, average cost overruns were 182%, while average schedule overruns were 202%!Disagreement with the CHAOS reportThe Rise and Fall of the Chaos report FiguresProjects failure rate – the conventional wisdom is wrong!The “Chaos Report” Myth BustersNew IT project failure metrics: is Standish wrong?
14 Has the Current State of IT Projects Changed Since 1994? The Standish Group has continued to study IT projects over the years.In general, IT Projects are showing higher success rates due toBetter project management tools & processesSmaller projectsImproved communication among stakeholdersMore skillful IT project managersBut there is still ample opportunity for improvement!
15 Figure 1.1 - Summary of the Chaos Studies from 1994 to 2008
16 Table 1.1 Summary of CHAOS Study Factor Rankings for Successful Projects Sources: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995, 2010) &Rank19942001200620081User InvolvementExecutive Support2Executive Management Support3Clear Statement of RequirementsExperienced Project ManagerClear Business ObjectivesClear Business Objectives4Proper PlanningOptimizing ScopeEmotional Maturity5Realistic ExpectationsMinimized ScopeAgile Process6Smaller Project MilestonesStandard Software InfrastructureProject Management Expertise7Competent StaffFirm Basic RequirementsFinancial Management8OwnershipFormal MethodologySkilled Resources9Clear Vision & ObjectivesReliable EstimatesExecution10Hard-working, focused teamOtherStandard Tools and InfrastructureTools & Infrastructure
17 IT Project Performance Over the Past 3 Years Table 1.2: Project Performance and Internal/External Customer Satisfaction.Source: Marchewka, J.T. (2008). n = 114.IT Project Performance Over the Past 3 YearsMuchWorseSameBetterAbility to meet project schedules0.0%12.3%40.4%41.2%6.1%Ability to meet project budgets1.8%10.5%44.7%37.7%5.3%Ability to complete project scope or system requirements2.6%7.0%7.9%Customer satisfaction over the past 3 years (Customers can be internal – e.g., HR department or external – e.g., a particular client)Overall satisfaction of the customer13.2%34.2%39.5%11.4%Perceived value of the delivered product to the customer9.6%38.6%Potential for future work with the customer0.9%3.5%42.1%14.9%
18 Criteria Response Schedule Scope Money Quality Staff Table 1.2: IT Project Success CriteriaSource: Source:CriteriaResponseSchedule61.3% said it is more important to deliver a system when it is ready to be shipped than to deliver it on time.Scope87.3% said that meeting the actual needs of stakeholders is more important than building the system to specification.Money79.6% said that providing the best return on investment (ROI) is more important than delivering a system under budget.Quality87.3% said that delivering high quality is more important than delivering on time and on budget.Staff75.8% said that having a mentally and physically healthy workplace is more important than delivering on time and on budget.
19 Factors for Challenged Projects Factors for Failed (Impaired) Projects Table 1.3: Summary of Factor Rankings for Challenged and Failed (Impaired) ProjectsSource: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995)RankFactors for Challenged ProjectsFactors for Failed (Impaired) Projects1Lack of user inputIncomplete requirements2Lack of user involvement3Changing requirements & specificationsLack of resources4Lack of executive supportUnrealistic expectations5Technology incompetence67Lack of planning8Unclear objectivesDidn’t need it any longer9Unrealistic time framesLack of IT management10New technologyTechnology illiteracy
20 Tata Consultancy Services 2007 Report Included 800 senior IT managers from the UK, US, France, Germany, India, Japan, & Singapore:62% of the IT projects failed to meet their schedules49% experienced budget overruns47% experienced higher-than expected maintenance costs41% failed to deliver the expected business value and ROI
22 Improving the likelihood of success A Value-Driven ApproachPlain & Simple: IT Projects must provide value to the organization not just completed on time and within budgetSocio-technical ApproachIt’s not just about the technology or building a better mouse trap. Must bring value to the organization. Clients/stakeholders must take an active, participatory role
23 Improving the likelihood of success Project Management ApproachSuccess depends not just on the team but more on the methodology (the set of processes and infrastructure) in placeStep-by-step activities, processes, tools, quality standards, controls and deliverablesKnowledge Management ApproachSystematic process for acquiring, creating, synthesizing, sharing and using information, insights, and experiences to transform ideas into business valuelessons learnedbest practices
24 Improving the likelihood of success Why project management should support IT projectsPM enables a company to make the best use of limited resources. Projects can drain or divert resources away from other projects and areas of the organization so investing them wisely is critical.To best meet client’s expectations, PM provides the means to deliver quality products and services in a professional manner (status reports, communications).Facing competition from outside vendors, good PM practices can enable internal IT departments to remain competitive in acquiring new business and talent.Enables an organization to be more efficient (do the right thing) and effective (do the thing right).PM enables shorter development time, lower costs and higher qualityPM must be supported and accepted at all levels of the organization.
25 The PMBOK® Guide’s Definitions for Project and Project Management A project is a temporary endeavor undertaken to create a unique product, service, or result.Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Managing a project includes:Identifying requirementsEstablishing clear and achievable objectivesBalancing the competing demands for quality, scope, time, and costAdapting the specifications, plans, and approaches to the different concerns and expectations of the various stakeholdersA project manager is the person assigned by the performing organization to achieve the project objectives.
26 The Context of Project Management – Project Attributes Time Frame (definite start and end)Purpose (project needs a specific and measurable goal in order to provide value)Ownership (sponsor)Resources (the triple constraint)Roles (different skill sets needed on a project)Project ManagerProject SponsorSubject Matter Expert (domain & technical)Risk & Assumptions (internal and external risks)Interdependent Tasksprogressive elaboration – steps & incrementsPlanned Organizational ChangeOperate in Environments Larger than the Project ItselfCompany culture, environment, politics, etc.
28 The Project Life Cycle and IT Development Project Life Cycle (PLC)A collection of logical stages or phases that maps the life of a project from its beginning to its end in order to define, build, and deliver the product of the project – i.e., the information systemA deliverable is a tangible and verifiable product of workProjects are divided into phases to increase manageability and reduce riskPhase exits, stage gates, or kill points are decision points at the end of each phase to evaluate performance or to correct problems or cancel the projectFast tracking is the overlapping of phases to reduce the project’s scheduleCan be risky!
29 The Project Life Cycle Define Project Goal Plan Project Focus on providing business value to the organizationGives the project team a clear focus and drives the other phases of the projectPlan ProjectWhat is to be done, why is it being done, how will it be done, who is going to do it, how long will it take, how much will it cost, what can go wrong and what can be done about it, how will we know if the project is successful given the time, money and resources invested?Deliverable is the initial or baseline project planExecute Project PlanPut the plan in action – build whatever product has been decided based on plan specificationsA continuous monitoring of the actual vs baseline is needed
30 The Project Life Cycle Close Project Evaluate Project A formal closure of the project ensures that all work is completed as planned and agreed to by the team and sponsorFinal report and presentation to the clientEvaluate ProjectEvaluating whether a project met its goals (providing business value) is best done after implementation when it is in productionLessons learned – document experiences and best practices for future projectsWhat went right and what went wrongEvaluate the project manager and team members
32 Systems Development Life Cycle (SDLC) Although projects follow a project life cycle, information systems development follows a product life cycle.The most common product life cycle in IT is the systems development life cycle, which represents the sequential phases or stages an information system follows throughout its useful life.The SDLC establishes a logical order or sequence in which the system development activities occur and indicates whether to proceed from one system development activity to the nextPlanningThe planning stage involves identifying and responding to a problem or opportunity and incorporates the project management and system development processes and activities.A formal planning process ensures that the goal, scope, budget, schedule, technology, and system development processes, methods, and tools are in place.
33 Systems Development Life Cycle (SDLC) AnalysisThe analysis phase attempts to delve into the problem or opportunity more fully.For example, the project team may document the current system to develop an "as is" model to understand the system currently in place. ,Systems analysts will meet with various stakeholders (users, managers, customers, etc.) to learn more about the problem or opportunity. This work is done to identify and document any problems or bottlenecks associated with the current system.The "as is" analysis is followed by a requirements analysis where the specific needs and requirements for the new system are identified and documented.Requirements can be developed through a number of means— interviewing, joint applications development (JAD), conducting surveys, observing work processes, and reading company reports.Using modeling techniques, the current system, user requirements, and logical design of the future system called the "to be" system are represented and documented
34 Systems Development Life Cycle (SDLC) DesignThe project team uses the requirements and "to be" logical models as input for designing the architecture to support the new information system.This architecture includes designing the network, hardware configuration, databases, user interface, and application programs.ImplementationIncludes the development or construction of the system, testing, and installation.In addition, training, support, and documentation must be in place.Maintenance and SupportOnce the system has been implemented, it is said to be in production and becomes a legacy systemChanges to the system, in the form of maintenance and enhancements, are often requested to fix any discovered errors (i.e., bugs) within the system, to add any features that were not incorporated into the original design, or to adjust to a changing business environment.
35 Systems Development Life Cycle (SDLC) Figure 1.5
36 Implementing the (SDLC) A structured approach to systems development has been around since the 1960s and 1970s, when large mainframe applications were developed.The waterfall model illustrated was developed as a simple and disciplined method that follows the SDLC closely in a very sequential and structured way.The idea of a waterfall is a metaphor for a cascading of activities from one phase to the next where one phase is completed before the next phase is started.The waterfall model stresses a sequential and logical flow of software development activities.Design activities or tasks begin only after the requirements are defined completely.The building or coding activities will not start until the design phase is complete.Although there is some iteration where the developers can go back to a previous stage, it is not always easy or desirable.One characteristic of the waterfall model is that a great deal of time and effort is spent in the early phases getting the requirements and design right because it is more expensive to fix a bug or add a missing requirement in the later phases of the project.
37 Implementing the (SDLC) An advantage of the waterfall model is that it allows us to plan each phase in detail so that the project schedule and budget can be computed by summing the time and cost estimates for all the tasks defined in each phase.This approach is still used today, especially for large government systems and by companies that develop shrink wrap or commercial software packages.A structured approach is suitable when developing large, more complex systems where one assumes, or at least hopes, that the requirements defined in the early phases do not change very much over the remainder of the project.
38 Putting the SDLC into Practice Structured Approach to Systems DevelopmentWaterfall MethodIterative DevelopmentRapid Applications Development (RAD)PrototypingSpiral DevelopmentExtreme Programming
39 Iterative Systems Development Critics of the structured approach to systems development argue that it takes too long to develop systems and that it does not embrace the idea that changing requirements are inevitable.Inexperienced developers often have the false belief that if they ask the users what they want, they will be rewarded with a set of clear, accurate, and complete requirements.In truth, most users do not know or are unable to articulate their needs early on in the project. If they do, those requirements will most likely change later on.The main idea behind iterative systems development is shortening the SDLC and embracing the idea that requirements are difficult to define and will change.
40 Iterative Systems Development Rapid applications development (RAD ) was proposed by James Martin in the early 1990s as a less formal way to expedite the SDLC.RAD attempts to compress the analysis, design, build, and test activities of the SDLC into a series of short iterations or development cycles.For example, a small team of users and developers would work closely together to develop a set of system requirements during a workshop.Using tools such as computer- aided software engineering (e. g., CASE) or visual development environments (e. g., .NET), the developers would then work with the users to develop a functional or usable version of the system that might include only 25 per- cent of the total requirements.The development cycle would continue with a second usable version that would include the next 25 percent of the requirements. Subsequent iterations would continue until all of the requirements are included in the system.
42 Iterative Systems Development Prototyping, similar to RAD, is an iterative approach to systems development where the user and developer work closely together to develop a partially or fully functional system as soon as possible.Often, however, a prototype may be developed to discover or refine system requirement specifications that can be used as a model for developing a real system.A team may develop a nonfunctional user interface on a personal computer as a model to define the look, feel, and features of a large, multi-user system.
43 Iterative Systems Development Spiral development approach first proposed by Barry Boehm (1988), breaks up a software project into a number of mini-projects that address one or more major risks until all the risks have been addressed.A risk, could be a poorly understood requirement or a potential technical problem or system performance issue.The basic idea is to begin development of a system on a small scale where risks can be identified.Once identified, the development team then develops a plan for addressing these risks and evaluates various alternatives.Next, deliverables for the iteration are identified, developed, and verified before planning and committing to the next iteration.As a result, the completion of each iteration brings the project closer to a fully functional system.
45 Iterative Systems Development Agile systems development methods are becoming an increasingly popular approach to systems development and include various methodologies such as SCRUM, dynamic systems development method (DSDM), and adaptive software development (ASD).One of the most commonly known agile methodologies is eXtreme programming (XP), which was introduced by Kent Beck in the mid-1990s.Under XP, the system is transferred to the users in a series of versions called releases.A release may be developed using several iterations that are developed and tested within a few weeks or months. Each release is a working system that includes only one or several functions that are part of the full system specifications.XP includes a number of activities where the user requirements are first documented as a user story. The user stories are then documented using an object-oriented model called a class diagram.A set of acceptance tests is then developed for each user story. Releases that pass the acceptance tests are then considered complete.Small teams of developers often work in a common room where workstations are positioned in the middle and a workspace for each team member is provided around the perimeter.XP often incorporates team programming, where two programmers work together on the same workstation.Developers often are prohibited from working more than 40 hours a week in order to avoid burnout and the mistakes that often occur because of fatigue
46 Agile Software Development Agile software development has become popular to describe new approaches that focus on close collaboration between programming teams and business expertsVisit for information
48 SCRUM Software Development SCRUM breaks a software development into a series of iterations or sprints. Each sprint lasts at most 30 days. During each sprint, a set of features are incrementally added to the product under development and a potential release of software is created.The requirements for the product to be developed are held in a product backlog.At the start of a sprint, a sprint planning meeting is held. During the meeting, a set of requirements from the backlog are picked for implementation in the next sprint. The development team decides which requirements they can commit to developing during the next sprint.At the end of a sprint, a sprint retrospective meeting is held to discuss which elements of the process could be improved.Further sprints are then performed until the product backlog of requirements is empty.
49 The Relationship Between the PLC & SDLC The project life cycle (PLC) focuses on the phases, processes, tools, knowledge and skills for managing a project, while the system development life cycle (SDLC) focuses on creating and implementing the project’s product—the information system.The SDLC is really part of the PLC because many of the development activities occur during the execution phase of the PLC.The last two phases of the PLC, close project and evaluate project, occur after the implementation of the system
50 The Relationship Between the PLC & SDLC Figure 1.7
51 Extreme Project Management (XPM) A new approach & philosophy to project management that is becoming increasingly popularCharacterizes many of today’s projects that exemplify speed, uncertainty, changing requirements, and high risksTraditional project management often takes an orderly approach while, XPM embraces the fact that projects are often chaotic and unpredictableXPM focuses on flexibility, adaptability, and innovationXPM takes a more holistic view of planning and managing projectsExpects requirement changes so planning is an iterative processEnables people to discover best solutions and self-correct themselves as needed
52 The Project Management Body of Knowledge (PMBOK®) The Guide to the Project Management Body of Knowledge (PMBOK® Guide) documents 9 project management knowledge areasThe PMBOK® Guide is published and maintained by the Project Management Institute (PMI)PMI provides a certification in project management called the Project Management Professional (PMP) that many people today believe will be as relevant as a CPA certificationPMP certification requires that you pass a PMP certification exam to demonstrate a level of understanding about project management, as well as satisfy education & experience requirements and agree to a professional code of conduct
53 Project Management Body of Knowledge Areas Figure 1.8
55 Project Management Body of Knowledge Areas Knowledge areas describe the key competencies that project managers must develop4 core knowledge areas lead to specific project objectives (scope, time, cost, and quality)4 facilitating knowledge areas are the means through which the project objectives are achieved (human resources, communication, risk, and procurement management1 knowledge area (project integration management) affects and is affected by all of the other knowledge areasAll knowledge areas are important!