Presentation is loading. Please wait.

Presentation is loading. Please wait.

CIS 310 Management Information Systems Project Management

Similar presentations


Presentation on theme: "CIS 310 Management Information Systems Project Management"— Presentation transcript:

1 CIS 310 Management Information Systems Project Management
This module is about project management.

2 IBM FAA Stix, Gary Aging airways. Scientific American, 271(5): Need to replace Air Traffic Control System (ATCS) machinery not-maintainable increase in traffic need to support new technologies 1982: 11 year, $12.6 billion redesign of the ATCS 1994: 150 projects, $36 billion by 2001 Today – Still a multi-billion dollar problem, not expected to complete until (Information Week). I’m going to go over three cases that ran into problems. This is what being a great project manager is all about, avoiding these problems. In 1982, the FAA software for the Air Traffic Control System (ATCS) was very out of date. This is the software that helps air traffic controllers land planes so it is pretty important. The system has to be % up-time and cannot have any errors. In 1982, the old system was so out of date that much of the machinery was becoming non-maintainable. They didn’t make the parts anymore to maintain the systems they had. Also, air travel had increased, so that the demand was too much for the existing system. The FAA needed a redesign that would modernize the system to support new technology and keep the high level of air traffic safety. It was projected to be an 11 year, $12.6 billion project. By 1995, 12 years later, it had expanded to 150 different projects, projected to cost $36 billion by That is a giant cost and schedule overrun. Today, the ATCS is still having problems with upgrades and is still a multi-billion dollar problem.

3 LAUSD Payroll LAUSD hired Deloitte to implement an SAP Payroll system.
LAUSD has highly complex labor agreements. $95 million expected to grow to $210 million. When the system went live, many teachers were unpaid or paid the wrong amount. Ugly finger pointing on both sides. Took years to fix the problem. Another example of a project that didn’t go so well was something that you may have heard about in the news a few years ago in LAUSD needed to upgrade it’s payroll system. By modernizing it, it was believed that there would be an improvement in the cost of the system and in the accuracy of the reporting. LAUSD hired Deloitte to implement SAP. LAUSD has a lot of complex labor agreements that we not well documented or even understood. SAP is a more cookie-cutter, off-the-shelf solution to payroll. Customizing a system like SAP is very expensive. Deloitte probably underestimated the complexity and LAUSD probably didn’t understand what the customization would cost and what needed to be done to make it accurate. So, after several years, instead of $95 million, the system cost $210 million. On the date that they chose to ‘go live’, teachers had a variety of problems with their paychecks, including not getting paid at all. It became a public scandal and Deloitte, perhaps unprofessionally blamed LAUSD and LAUSD blamed them. It got pretty ugly. It took until 2012 to fix the problems associated with this implementation. While not a failure, it isn’t what you want people to think about your company either.

4 US Air Force Logistics Chris Kanaracus, Air Force scraps massive ERP project after racking up $1B in costs, ComputerWorld, 11/14/12. “$1.03 billion in costs since 2005, "and has not yielded any significant military capability” “$1.1B for about a quarter of the original scope to continue and fielding would not be until 2020.” Project terminated. "Why did it take the [Air Force] $1 billion and almost 10 years to realize this project is a disaster? What kind of planning process accepts a billion dollars of waste?“ (Krigsman IT Failure Expert) This case, we may have discussed already. Chris Kanaracus from ComputerWorld, 2012, writes about the implementation of an ERP system for Air Force acquisitions. In 2005, the system cast about a billion dollars and the project had no significant delivery, milestone or measure of success. A billion dollars and nothing to show for it. Ouch. It was projected that the project would cost a billion more and would not be complete until The project was terminated. In Kanaracus’s article, Krigsman and IT failure expert, was quoted as saying: "Why did it take the [Air Force] $1 billion and almost 10 years to realize this project is a disaster? What kind of planning process accepts a billion dollars of waste?“ He’s right, how can this much spending occur without project control to more the project forward or cancel it before this much waste occurs. It is really astounding.

5 IT Systems Development Projects In General
Overrun Late Failures Backlog Dissatisfied Users That is the essence of why we need great project managers, so overruns and delays like that will not happed. In general, IT projects can be overrun, late, failures, and have lots of dis-satisfied users. The IT department has a backlog of projects that will not be done because of lack of resources. So, the IT department prioritizes what projects will have the most payoff. This also leaves users unsatisfied if their projects are not chosen. It projects fail for several reasons. Incomplete requirements – 13% Lack of user involvement – 12% Unrealistic expectations – 10% Lack of executive support – 9% Changing requirements – 9% Lack of planning – 8% And a variety of other reasons.

6 Standish Group, Chaos Report
On schedule on budget is getting better ZDNET – Does Standish have it Wrong? Executives vs. PMs Breakdown of Challenged Projects There is a consulting group, the Standish Group, that has become infamous each year for providing the public with the chaos report. In the report, percentages for software projects that are successful, challenged and failures are provided. In 1994, the % of IT projects that failed was 31%. In 2009, it is 24%. That is a better number but, it is still a big number – roughly a quarter of IT projects end in failure. Recently, ZDNET reported “Does Standish Have it Wrong?” the author claimed that the way the Standish group collected the statistics was flawed. They surveyed executives, not project managers. But an executive view might be quite different. An executive may have expected more, or may have been oversold on the capabilities and payoffs of the project. ZDNET also suggested that the Challenged category be broken down into why those project had trouble. Many may have had budget cuts, which required projects to adjust. However, that isn’t necessarily a failing of the software development effort.

7 Project Management There are several reasons and intricacies for why projects fail. Great Project Management can help avoid problems. Project Manager Characteristics Communicator Organized Foresight Leadership Pragmatic There are many reasons why an IT project might fail. Great project management can often get a project off to the right start and keep the momentum going so it is highly successful. Many different sources report characteristics for a great project manager. Here are a few listed here: Communicator – great PMs need to communicate to all constituencies. Upper management, clients and end users and to the developers that work for them. Communication is the single greatest factor that can help a project succeed. Organized – Of course, anyone leading a project of any complexity needs to be organized. Foresight – An experienced PM can frequently see a problem before it becomes a giant problem. For example, if you know the electrical sub-system of your satellite is having a lot of problems, then you know the integration effort will be delayed. The sooner you can tell the client about this difficultly, the sooner they are prepared for a project slip. You may also know that you’ve got 5 weeks worth of software test at the end of the program. By ramping up the manpower in test, you may be able to make up some of the time you lost fixing bugs in the electrical subsystem. Leadership – Being a person who has leadership charisma and presence can help to inspire confidence and good work from project stakeholders. Pragmatic – While the customer and the developers might want to add lots of features to a product, the reality is that there is a limited amount of money and a limited amount of time to produce something. Being diplomatic and practical can keep requirements from multiplying and can keep the project focused.

8 Project Management Certifications
Program Management Institute (PMI) Project Management Professional (PMP) Exam Exam Based Certification 4 Year College Degree 3 years of PM experience 4,500 hours leading and directing projects and 35 hours of project management education. In fact, project management is such a needed skill that there are now certifications for that. PMI, the Project Management Institute, is an organization that give training and exams on project management. PMI offers several certifications, the most popular being the Project Management Professional or PMP Certification. You may have seen several professionals on LinkedIn with this Cert. Before you can take the exam, you need 3 years of experience, a 4 year college degree, 4500 hours of directing projects and 35 hours of classroom project management education.

9 What Makes IT Projects Successful?
Upper management support User involvement Communication Clear, complete requirements Appropriate staffing Manage change Track and communicate progress Manage client expectations We’ve looked at why projects fail. Now, lets see what makes IT projects successful. Upper management support – having upper management support your project means that you will be successful getting the resources you need to develop it. For example, if you need people to staff your project and you’re competing with other projects, having an ally in management to give you what you want, works really well. User involvement – Involving the user as early and as often as possible can only help you to meet their needs. Communication – Sometimes technology can help facilitate communication. Frequent, clear communication can help project team members at every level avoid conflict and misunderstandings. Clear, complete requirements – You will never, ever have this. But, the closer you can get, the better. If you have ambiguity about the requirements at the beginning of the project, it will become more expensive to change them as the project progresses. Appropriate staffing – Of course, you need the right people to do the job. If your firm needs to ramp up in a skill set that they don’t have, you may need the help of HR to make this happen quickly. Manage change – Any plan is subject to change. The Project changes, the requirements change, the client sometimes changes, people quit and the team sometimes changes. Being versatile and capable of managing those changes makes a project robust. Things don’t fold because of a little chaos. Track and communicate progress – to all constituencies. Everyone needs to know what the milestones are and how the team is meeting them. Manage client expectations – Do not exaggerate to your client. If there is bad news, use candor and diplomacy to let them know. If they find out that you will slip the delivery date a week before the project is due, they are going to be super mad. The minute you find real problems, you should be open and up-front with them. Don’t tell them that everything is 95% done, when you’re not clear about what that means.

10 Triple Constraint Time Money Scope (Requirements)
If any of these things change, the project changes. An increase in requirements leads to more cost and longer development time. Less money means you cannot deliver everything you had planned. Less time probably means less functionality in the final delivery. Projects are said to be held by the ‘triple constraint’; time, money and scope. Scope means requirements, the breadth of what will be developed in your project. If any one of these items change, the other two have to change. An increase in requirements leads to more cost and longer development time. Less money means you cannot deliver everything you had planned. Less time probably means less functionality in the final delivery.

11 Project Selection Project Portfolio
Typically there are more projects to do than an IT department has the resources for. Select a portfolio of projects that promote organizational objectives. Cost Benefit Analysis Potential for Success Political Support Efficiency and Effectiveness Some Risk Technology – Build Skills IT departments get several requests for projects that can help the company. Typically, there is a limited budget, personnel and time to do certain projects and some of the projects have a bigger impact than others. If your upper management says, do this project, that is the one you’ll do, of course. Then, you might look at projects that save the most money, are more likely to be successful or are high visibility for your departments. Another things to consider is building the skills of your IT staff. If a project is not high risk and gives your personnel a chance to learn a new technology and develop a new skill, that might be a good one to focus on. An IT department will have a portfolio of projects to accomplish and they need to balance, cost, risk and other factors to make the overall outcomes successful.

12 Project Management Tools
Classics Work Breakdown Structure (WBS) Pert chart (Critical Path) Gantt chart (Milestones) Others Workflow Financial Reporting There are many scheduling tools available to project managers. In fact, many are now Software as a Service, through cloud computing. The classic tools we thing of, associated with Project Management are Work Breakdown Structure or WBS, Pert Chart for measuring critical path and Gantt Chart to track project milestones. Other tools that help project managers are financial reporting and workflow tools.

13 Project Documents Request for Proposal (RFP) Contract
Work Breakdown Structure Requirements Specification Design Reviews Test Quality There are also several documents that support projects. These are just a few. Documenting what you do is very important because every document is a communication tool and often a legal document for the project. RFP is the document that sometimes starts a project. The client describes what they would like a system to do in detail and asks for competitive bids on the development. This is done in a Request for Proposal. Then, contractors bid on the project, demonstrating their competence in the tech area and what skills and resources their company brings to bear on the development. If your company wins the bid, then the company is awarded a contract and then has to perform all the work. The work is delineated in a WBS or Work Breakdown Structure. Then, as the project begins, a requirement specification is developed and all the other documentation, testing and schedules are based upon meeting those requirements.

14 Work Breakdown Structure (WBS)
1.0 Build Robot Housekeeper 90,000 hours | $10M 1.1 1.2 1.3 1.4 Requirements 4000 hours | $?K Analysis 6000 hours | $?K Programming 60,000 hours | $?K Integration & Test 20,000 hours | $?K This is a fake WBS structure for a project that will build a Robot Housekeeper, something everyone wants. At the top level, 1.0 designates the first level. I’ve said it would take 90,000 hours and $10 million. However, if you really think about it, it is probably more like 5 years, 20 developers and $100 million. But, the point is the money is broken down into a hierarchy of achievements that we’re trying to achieve on the project. Under the top level, in this picture, I’ve got 1.1 Requirements, 1.2 analysis, 1.3 Programming and 1.4 Integration and test. These would be broken down into an even lower level, for maybe the different subsystems of the robot. 1.2.1 1.2.2 1.2.3 1.2.4 Cleaning Subsystem 2000 hours | $?K Electrical Subsystem 1000 hours | $?K Mobility Subsystem Communication Subsystem

15 Pert Chart Requirements Analysis Programming Test Integration & Test
Use Interface Commanding Requirements Analysis Programming Test Smart Mobility Commanding Design Review Robot Comm Substystem Integrate with Mobility Subsystem Integration & Test 4/19/2013 Requirements Analysis Programming Test Cleaning Subsystem Commanding This is a pert chart for the Robot Housekeeper, Communication Subsystem. The great thing about this chart is that it shows where the activities come together. These are critical points for the project and if one item leading into the point is delayed, it delays the entire project. So clearly, before the design review is held for the communication subsystem, I have to integrate and test all the different commanding subsystems. So, user interface commanding, smart mobility commanding, cleaning commanding and state-of-health commanding need to work together before I am ready for the design review. Each of those commanding subsystems needs to go through a requirements, analysis, programming and test phase before they get to integration. The pert chart gives me a way to view the entire project by how the different tasks depend upon one another. Requirements Analysis Programming Test State of Health Commanding

16 Gannt Chart This is a chart you are probably very familiar with. It is a Gantt Chart showing the tasks vertically down the left and the timeline horizontally across the top. The timeline is shown in weeks and there are 13 weeks shown on the chart. While the chart is generic, the way the tasks are displayed gives me clues as to how the project is running, not well. Look at WBS 1 Summary Element 1 I can see that the black represents what portion of the task is complete. The blue is what is remaining. 57% of the task is complete. I can also see the white and gray, dashed vertical line that says today. That shows me where my project was planned to be, relative to where I am. So I’m behind. If you look further down to WBS 2 Summary Element 2, you can see that it is 0% complete.

17 End Why is everyone so spun up about IT projects?
What is the triple constraint? What is an RFP? They cost money and IT has a history of overrun and late projects that clients are unhappy with. Time, Cost, Scope. If any one of these changes, the other two have to change. Quiz Time Why is everyone so spun up about IT projects? They cost money and IT has a history of overrun and late projects that clients are unhappy with. What is the triple constraint? Time, Cost, Scope. If any one of these changes, the other two have to change. What is an RFP? Request for Proposal. If your company builds systems, it is what you will bid on to get work. Request for Proposal. If your company builds systems, it is what you will bid on to get work.

18 CIS 310 Management Information Systems Systems Development
This is Ruth Guthrie presenting a module on Systems Development.

19 Systems Development Life Cycle (SDLC)
Also…Project Development Life Cycle or Software Development Life Cycle The process you follow to develop your systems. Problem definition/Planning Requirements analysis Design Code Test Maintain The systems development life cycle (SDLC) refers to the process a company goes through to develop a product, typically a software product. It is sometimes also called the project development life cycle or the software development life cycle. The phases are: Problem definition/Planning Requirements analysis Design Code Test Maintain

20 SDLC Phases Problem Definition/Planning – will the system improve efficiency, effectiveness? Define the project goals and develop a high level plan to meet them Requirements Analysis – Define in detail the functions and operations of the system. Design – Develop the structure and for how the system will work. This includes user interface design (front-end), data base design (back-end), interface descriptions…how it will work. The first phase of the SDLC is problem definition and planning. First we need to see that a problem or opportunity exits and then we need to think of a high-level plan to getting it developed. Will the system improve efficiency, effectiveness? Define the project goals and develop a high level plan to meet them After making a commitment to proceed with the project, requirements analysis is done. During analysis, the detail of the functionality and operations of the system are defined. During the design phase, all the structure and

21 SDLC Phases (contd.) Development – Code the design. Testing.
Test – Test to the requirements. (subsystem, system, integration, load, usability…etc.) Implement – Have the system go live. Maybe change-over from an old system. Maintain – Throughout the system life cycle, make changes that add functionality or improve the system. Development is the phase where all the coding is done. The designs that were constructed in the previous phase are actually built. Some level of testing is done during development too. During the test phase, the entire system is tested to the requirements. This is to ensure that the system does what you said it would do and typically, involve the customer and quality assurance. There are many kinds of tests that go into this phase depending upon what your project is. If it is an ecommerce web site, you might do load testing to make sure the site doesn’t crash during black Friday. During the implementation phase, the system is made operational so that people can use it. This may involve the phasing out of old systems or several old systems. After successful delivery of the system, typically, there is a maintenance contract to enhance the system or fix any problems that arise.

22 Traditional Model (Waterfall)
Requirements Analysis Design Code Test Maintain There are several different methodologies that are used by companies to implement systems. The oldest, structured methodology is called the waterfall model. The phase of the project are done sequentially, one after the other and typically, there is a big review or report and the end of each phase, indicating that the phase is complete. The problem is what if you make a mistake. The highly structured Waterfall model makes it difficult to change things without higher cost.

23 Waterfall Model Strengths
Simple to understand with well defined product milestones. Good for well understood, well defined projects with short time horizons. Protection against fickle customers in that specifications are concrete baselines. Requirements traceability Strengths of the waterfall model are: It is simple to understand with well defined product milestones. This can be a great tool to communicate with project stakeholders, especially the client. Good for well understood, well defined projects with short time horizons. Protection against fickle customers in that specifications are concrete baselines. Requirements traceability

24 Waterfall Model Weaknesses
Inflexible. Lengthy time between requirements and working model results in poorly met user needs and failure to leverage current technologies. Low customer satisfaction. High cost. Weaknesses of the Waterfall model are: It is really inflexible. Lengthy time between requirements and working model results in poorly met user needs and failure to leverage current technologies. Low customer satisfaction. High cost.

25 Incremental Development
Requirements Design Implement Requirements Design Implement Requirements Design Implement Incremental design is our next methodology. It seeks to mitigate some of the weaknesses of the waterfall model by breaking a big problem down into smaller pieces. A great example of this is an implementation of an enterprise wide information system, like SAP. A company first implements payroll, then accounting, then human resources. By doing this, earlier accomplishment is made in that a subset of the entire system is operational before the project is done. Then as new subsystems are implemented, integration cycles join the operational systems together. Things that you learn during the first increment can inform the requirements and processes for future implementations.

26 Incremental Development
Strengths Some flexibility on requirements. Breaks large systems problems into achievable pieces Weaknesses Requires well defined interfaces Costly. Many integration cycles. Tendency to delay difficult problems Strengths of incremental development are that it offers some flexibility on requirements and it breaks a giant project into smaller, achievable pieces. Weaknesses of this model include that fact that to do many integrations well requires that you define the interfaces, thoroughly before hand. It is also quite costly because of all the integration. Projects using incremental development have a tendency to delay difficult problems till the end of the project.

27 Prototyping clearly defined requirements customer working requirements
mock-up customer test and feedback robust development Prototyping is a tool that helps developers really understand requirements early in the project life cycle. Using prototyping, a mock-up of the user interface is created so that users can actually ‘try’ the system and then give feedback to the developers on how well it meets their needs. Typically, a prototype will run through several iterations before all the requirements are known. Having the users see what the system will look like visually makes it much easier for them to articulate what they want than asking them ‘what are your requirements’ directly.

28 Prototyping Strengths
Early functionality. Good risk control. Solves problem of identifying customer requirements by providing operational mock-up. Higher customer satisfaction. Development is highly focused on end-product. Strengths of prototyping are: It provides a view of early functionality to the users. It gives good control of risk in that the requirements are well defined. It solves problem of identifying customer requirements by providing operational mock-up. Higher customer satisfaction. Development is highly focused on end-product.

29 Prototyping Weaknesses
Use of prototype as system causes problems. Customers do not understand why they cannot use the system since it is ‘working’. Disappointed with development time. Sometimes results in system with poor performance and documentation. Delay difficult problems. Not highly applicable to maintenance projects. Prototyping weaknesses: Use of prototype as system causes problems. Customers do not understand why they cannot use the system since it is ‘working’. Disappointed with development time. Sometimes results in system with poor performance and documentation. Delay difficult problems. Not highly applicable to maintenance projects.

30 Evolutionary (Spiral) Model
1. Determine objectives, alternatives, constraints 2. Evaluate alternatives, identify, resolve risks Commit This is a picture of the Evolutionary Spiral Model. This model attempts to control development by focusing a lot on risk reduction. There are 4 phases. Determine objectives, alternatives and constraints. Evaluate alternatives, identify, resolve risks. Develop, verify next-level product. Plan next phase. By focusing on risks and how to mitigate them, and by letting the requirements evolve as the system develops, user needs are easier to implement. 4. Plan next phases 3. Develop, verify next-level product

31 This is another diagram of the Evolutionary Spiral with a little more detail in it. Again, the thing to remember is that the spiral model focuses on minimizing risk. So there are many spirals that fold up into the final project but, for each one, risks are identified, assessed and mitigated.

32 Spiral Pros & Cons Pros Cons
Flexible so you have a better chance of meeting the users needs. Risk is well managed. Good for a complex project. Costs get more accurate as the project progresses. Cons Can be expensive and complicated Too complex for a simple project Too much documentation Need experienced project manager Advantages of the Evolutionary Spiral Model is that it is flexible. You do not need to have all the requirements defined at the beginning, so you can change to meet the changing needs of the user along the development life cycle. Disadvantages of this methodology are that it can be expensive and complicated. For a simple project, this methodology would not be appropriate. This methodology is also very documentation heavy and requires a really experience project manager to make it successful.

33 Agile/SCRUM The final methodology we’ll discuss is called Agile/Scrum. Agile is actually a set of methodologies that describe, like the evolutionary spiral, a process that breaks deliveries down into Sprints, instead of Spirals. This may even look a little like the Evolutionary Spiral Model. The difference is that the Sprints are purposely prioritized to put the highest priority items for the client first. In this picture, you see a product backlog, that is our requirements specification. Sometimes these are called user stories. All the different requirements that a user might want are put into the product backlog. Then, a time estimate and a priority is given to each one. The requirements are divided into Sprints and developed in a short period of time. A sprint review is held and the user gets to test the product. Early functionality of what the user most cares about is what drives scrum development. Then as requirements become more clear, they may be added to the project. If the funding is lost, the user at least has their highest priority item already developed, which makes them happy. Prioritize sprints so the most important features are done first. Functionality at every delivery.

34 Scrum Project Team: Scrum Master, Scrum Team, Product Owner
Develop Requirements (User Stories) Prioritize and divide requirements into sprints Deliver a few sprints every 2-3 weeks and change the requirements as you go Sprint reviews with the user Emphasize added functionality after each sprint This is the typical process flow for a scum team. The scrum team consists of a scrum master, team members or developers and a product owner. First, the scrum team develops requirement or user stories. Using the perspective of the user, the developers try to write the requirements in terms of what functionality the users want the system to have. Then the team estimates how much time it will take to develop each requirements and develops priorities, based upon the customer needs. The highest priorities of the system get developed first. Several requirements are categorized together to form a sprint and sprints are delivered every 2 or 3 weeks. That way, frequent customer feedback is sought and changes can be made to meet the changing customer requirements. Lowest priority sprints are scheduled at the end of the project. So, when the timeline and money are running shorter, the customer has the option to not add the ‘nice-to-have’ features because the ‘need-to-have’ ones are complete.

35 Scrum Pros & Cons Pro Con Early functionality makes customers happy
Small teams are more efficient Requirements flexibility allows for change Con Hard to manage something that isn’t well defined A lot of time is spent in reviews The requirements change a lot. So time is spent on redesign. Difficult for a complex project. Scrum Advantages are: Early functionality makes customers happy Small teams are more efficient Requirements flexibility allows for change Disadvantages are: Hard to manage something that isn’t well defined A lot of time is spent in reviews The requirements change a lot. So time is spent on redesign. Difficult for a complex project.

36 Summary Waterfall Incremental Development Prototyping
Spiral Development Agile/Scrum To summarize, we looked at 5 different development methodologies. Waterfall - a top down methodology where each phase of the life cycle occurs one after the other. Incremental development - where a large project is broken down into smaller sub-projects. Prototyping – having a live mockup of the system so users can try it out, giving a project greater understanding of requirements. Spiral Development – Breaking a project down into several small spirals and letting the requirements change as the project evolves. Agile/Scrum – Having small project teams develop sprints, focusing on early functionality to the user and requiring several short delivery cycles.

37 End If your project is well understood and highly structured, what methodology might work for you? If you are expecting requirements to change and evolve as the project grows, what type of methodology should you use? What ultimately happens if you blow it on the requirements in the beginning of the project? Waterfall Scrum or maybe rapid prototyping. Quiz Time If your project is well understood and highly structured, what methodology might work for you? Waterfall If you are expecting requirements to change and evolve as the project grows, what type of methodology should you use? Scrum or maybe rapid prototyping. What ultimately happens if you blow it on the requirements in the beginning of the project? It costs more money to fix towards the end of the life cycle. It costs more money to fix towards the end of the life cycle.

38 References Stix, G Aging airways. Scientific American, 271(5): Hoover, J. 2011, Problems Plague FAA's NextGen Air Traffic Control Upgrade, Information Week. Chris Kanaracus, Air Force scraps massive ERP project after racking up $1B in costs, ComputerWorld, 11/14/12. References


Download ppt "CIS 310 Management Information Systems Project Management"

Similar presentations


Ads by Google