What are the most common problems with IT projects?
Here are some examples of the it project management challenges and project issue:
Incorrectly defined business requirements
No wonder that as many as 39% of unsuccessful projects fail since business requirements have not been appropriately defined. You can't build something that does what it should, meet its goals, and makes sponsors happy when you don't have reasonable job requirements - much less you can't get it all done on time and budget. Very often, the reason is that the conditions are created in isolation from the development team, which then has to take responsibility for their implementation.
A business team often works on collecting requirements for a year and creates a document that is 300 pages long. The development team then discovers architectural problems that affect most of the requirements, which means that they have to be changed a lot. Manager want to achieve business goals and satisfy customers. To avoid this problem, involve all subject matter experts - business partners, IT representatives, and even end-users - in the IT project requirements phase. Business representatives work with end-users to document the "what" goals of the IT project. IT representatives consider "how" - the best way to build what is required. When these two things happen simultaneously, the risk of the IT project failure from inadequate or incorrect requirements is significantly reduced.
Case Study: Qantas In 2008, the national airline Qantas-Australia canceled its $ 40 million Jetsmart projects.
Jet smart was a project to build a parts management system for the company's aircraft mechanics. Unfortunately, the solution was so poorly designed and complicated that the aircraft mechanics refused to use it. Qantas officials later stated that they built what they thought was right rather than asking the mechanics what they needed. Without involving the relevant subject matter experts - end-users - Qantas had to give up the costly PR.
IT Project sponsors were not involved
Another big problem is that IT project sponsors communicate high-level requirements and wait for the finished product to be delivered. This is called development in a vacuum.
This way, teams cannot contact any representative when questions arise. Instead, they are forced to make the best of guesswork and develop further. If they guess wrong, a business won't know until development is complete.
This leads to dissatisfaction with IT project sponsors, unreleasable products, and complex changes that make the project delayed and over budget.
According to a 2017 PMI survey, inadequate sponsorship accounts for 27 percent of unsuccessful IT projects.
To avoid this setback, make sure the project sponsor or other designated business representative is involved in the development phase.
The business sponsor answers the development team's questions about the requirements and reviews the work in progress to ensure that what was developed meets the original requirements.
Case Study: HealthCare.gov
Probably the most publicized setback of the IT project of the last decade was HealthCare.gov: a government project to build a website that allowed uninsured people to buy health insurance at a discounted price through private exchanges. HealthCare.gov was launched in October 2013, and problems arose. Immediately. The website was unable to serve the more than eight million users who visited it in the first days after its launch, so only 1% of people could register successfully.
Following an investigation, it turned out that poor communication and a significant lack of stakeholder participation were the two biggest reasons for the project's setback.
In his article on time, Steven Brill wrote: "No one in the White House at the pre-launch meetings had a clue that the technology was working." The White House's director of technology was deliberately excluded from project planning meetings.
Changes in IT project goals
Each IT project has three constraints: time, scope, and budget.
With the waterfall approach, time and scope are fixed, but budget is flexible. The development team provides all the required functionalities within the specified deadline. If this is not possible, teams add a budget to increase the amount of work they can complete in the allotted time.
With an Agile approach, time and budget are fixed, but scope is flexible. Realizing that little - if any IT project ever goes exactly as planned - Agile founders opted for a system that allows teams to re-prioritize as needed to ensure finished products meet their most pressing business needs and support business processes.
Most Agile teams operate within Scrum. Scrum teams work in short iterations that typically last from one week to one month. At the beginning of each iteration, the team plans its work. The plan cannot change during iteration, but each new iteration provides an opportunity to change the plan. There is a scrum master and project manager to keep an eye on it. The job need to be done.
It may be impossible to control a change in IT projects goals, but it is possible to minimize the impact of changing goals by working in a model that supports change as needed.
Changing design goals owes 36 percent of unsuccessful IT projects, but plan changes don't necessarily lead to setback. Minimize this risk by shortening the time frame of your plans.
Plan your work in two-week iterations: determine which set of work is the most important and focus on the tasks you can complete during those two weeks. This keeps the development team always focused on the highest priority work and consistently delivered the releasable code. Remember to hire a great IT project manager for your It project.
Case study: Virtual case file
From 2000 to 2005, programmers from the FBI worked on the Virtual Case File system - a system that was intended to modernize office IT systems and replace the old case management platform. After five years and nearly $ 170 million, the project was abandoned.
The case's virtual documentation was deemed "incomplete, inadequate and so poorly designed that under real conditions, it would be essentially useless."
The team signing the software development contract emphasized that the problems arose from the extensive scope and frequent changes to the IT project specifications.
The uncertainty cone presented above is a graph intended to explain the problem with project estimates.
In the earliest phases of a project, estimates are - in the best-educated guess (I don't understand this sentence). Since teams know so little about design requirements and dependencies, cost and time estimates can be four times or four times less than actual costs and time frame for implementation.
As requirements mature and development begins, this variability diminishes, but the only time it is zero is when the project is complete.
Variable, however, estimates are a necessary evil in IT projects, as few business sponsors are willing to return a blank check. Before approving a IT project, sponsors need to have some idea of whether they can afford the costs and whether the price is worth the investment or not.
However, inaccurate estimates are not the direct cause of project failure - even when reported as the cause of failure in 28% of IT projects. Approximate estimates are the result of two main factors:
Poor Estimating Practices - Inexperienced development teams will often provide estimates assuming everything will go smoothly without underestimating time and cost.
Planning -IT Project managers request an estimate too soon but never go back to the project team to determine if the estimate is still feasible. The solution to this problem depends on its cause:
Inappropriate estimation practices: Provide estimates over time. For example, if developers estimate it will take them a month to complete a project, look at the cone of uncertainty for the range that corresponds to the project's current phase. If you are in the initiation phase, give your estimate as .25x-4x, or "one week to four months."
Initial estimates: if they cause problems with the estimates, they should be planned and re-estimated more frequently. Get an estimate in the initiation phase, then ask the development team to come back to it once the requirements are met. During development, ask the team to continuously review the plan to determine if the project is still on track.
With proper planning and estimation, teams can typically deliver something on time and within budget - even if it's not 100% of the requested scope. Keep in mind that for a project sponsor, getting less than expected is always better than getting nothing.
Case Study: Denver International Airport Baggage Handling System.
In the 1990s, the city of Denver decided to build a new airport to accommodate more people using the existing airport. Part of the design of the new facility was an automated baggage handling system that would cut flight times by 30 minutes.
Unfortunately, the complexity of building a new baggage handling system has been grossly underestimated. The baggage handling system alone delayed the airport's opening by 16 months and cost the city of Denver $ 1.1 million a day during the delay.
Although a version of the baggage handling system was finally released, it never worked as planned - even after long delays and additional costs of $ 560 million - and was eventually altogether scrapped in 2005.
There are three types of risk for any project:
Known risks that you know about and can plan to mitigate. For example, you are dependent on another team completing coding before work begins, but this other team has yet to commit to achieving it. Because you know about this risk, you can plan for a worst-case scenario.
• Problems you know can become risks. For example, the team you depend on has committed to delivering its code by a specific date but is notoriously late. Even if it does not risk yet, you know it can become one, so you can plan accordingly.
• Unknown risk - a risk that catches you suddenly. For example, halfway through the code, you discover a dependency on a team that you haven't spoken to at all. This is a considerable risk as there is no guarantee that the other team will be able to do the work that you now need from them.
These risks account for 27% of project failures. The solution to unexpected troubles is the same as the solution to inaccurate estimates. To avoid project failure due to unpredictable risk factors, estimates need to reflect both known and unknown risk factors.
The cone of uncertainty is intended for just this purpose. In the project initiation phase, your team estimates it will take a month to complete the coding. As there is still such a high potential for unknown unknowns, an estimate of four times as much should be provided to the project sponsor.
These additional three months will provide ample time to deal with any unexpected threats that may arise. At best, you will finish three months early. It is always better to tell the IT project sponsor that you will complete it earlier and under budget, than to say to them that the project will be late and cost more than planned.
Case study: A project to automate data collection in US Census Fields
In 2001, the US Census Bureau decided to initiate a project that would modernize how data is collected for the 2010 census. Instead of using paper forms, interviewers would build hand-held computers to collect survey data.
Unfortunately, this technology was more complicated to build than anticipated. After in-house development teams failed to develop the technology, the Census Bureau had to engage a supplier to complete its construction. However, the original failure left the supplier only one year to complete the project before the required test period.
Ultimately, the project was not completed on time, and the Census Bureau had to ask for an additional $ 3 billion to finance the 2010 paper-based census completion.
In the case of large and complex IT projects, numerous development teams are often involved. Sometimes they are internal teams from other departments that own and manage specific platforms or services. Sometimes, they are sales teams customizing a product or service to meet the customer's needs.
When other teams you depend on fail to deliver their commitments on time, it can ultimately push your project off track. Dependency-related delays are the cause of failure in 23% of unsuccessful projects.
The important thing here is that it isn't much you can do to rush the other teams and finish their part on time. However, you can reduce the risk through proper planning and estimation.
The dependency delays fall into the category of known unknowns. Though you can't be sure, the wait will occur - before it happens. You are aware that such a risk exists - always remember about proper planning. Use the uncertainty cone on other teams' estimates.
If they say it will take two weeks to deliver the needed changes, let's assume it can take up to two months and schedule it accordingly. Have your teamwork on a functionality that is not dependent on changes in another team, and if that is not possible, plan to wait for another team to finish the project before starting work on the IT project.
Case Study: Boeing's Dreamliner In 2004
Boeing launched its Dreamliner project to create an innovative, quieter, and more fuel-efficient aircraft. Project leaders decided to outsource most of their design, engineering, and manufacturing work, leaving Boeing the ultimate integration and assembly task.
Unfortunately, this decision led to many problems: delays in the delivery of parts by the supplier, the lack of documentation on how the systems were installed, and the receipt of fewer fasteners than necessary. Due to these problems, the Dreamliner shipped four years after its originally scheduled maiden flight, and the design cost twice as much as originally estimated.
IT Project managers often use the word "resources" to refer to people, so "insufficient resources" refers to not having enough people to do the project - people problems. This is the reason for 22% of unsuccessful projects. Issues with member of the team and quality of team is one of the most common it management problems.
As mentioned earlier, different the project management methodologies have various persistent limitations. In waterfall, it's a budget, meaning you have the means to add as many people as it takes to complete the job. In Agile, it's a scope, meaning you only engage as much work as existing project team member can do.
Projects that fail because there weren't enough people are usually the result of running projects with a fixed scope, budget, and timeframe. It does not work. One of the three constraints must be flexible to accommodate unforeseen risks.
Lack of adequate resources should never cause a project to fail - it could only be the cause of a project not started. With proper planning, it should be evident that there are not enough people to complete the required amount of work within the required time frame. The solution to this problem is to make one of the project's three-time budget or scope constraints more flexible.
If you need to deliver something within a specific timeframe and budget, commit to a smaller scope. If you need to provide the full scope within a particular time frame, wait for more resources before starting your project.
IT project management problem
The last IT project management challenges is all about proces and people responsible for this proces - IT it project managers. When a IT project is mismanaged, the signs are unmistakable. The budget is eaten up too fast; teams don't have the right goals. But the characters are only apparent if someone is monitoring the situation.
Creating a project plan is not enough. Someone has to monitor this plan. This could be the project manager, IT manager, or Scrum Master - it doesn't matter. You need the project manager to monitor your progress. Inadequate supervision over IT project management accounts for 20% of unsuccessful projects. To prevent this cause of failure, you must have a person responsible for monitoring progress against your project issues and goals.
If you assign supervision to someone with little IT project management experience, make sure you invest in training before starting the project. The type of training required is flexible. Outsource this person's long-term study for PMI certification or ask them to spend a few days learning about the types of planning exercises used in Agile.
Case study: Shared Services Transformation Program
The Shared Services Transformation Program was an IT project to be used by the UK Department of Transport. Once approved, the project's estimated cost was £ 55.4 million, but it would save £ 12.4 million over ten years.
Unfortunately, the numerous changes and unexpected complexities - coupled with little oversight of IT project management - caused delays and increased costs. Before the problem became apparent, the project's cost had risen to £ 121.2 million, while projected savings for the department had decreased to £ 40.1 million.
Due to the project's poor management, a project manager wasn't right person for the problem of this IT project. Which aimed to save 57 million pounds, actually cost 80 million pounds.
Team members procrastination
Accounting for 11% of unsuccessful projects, delay in team members goes hand in hand with poor IT project management and bad IT project managers. If developers are procrastinating - or if other team members the developers depend on are not delivering answers, high quality code, or services on time - it should be evident that the it project plan has gone off track.
In addition to monitoring the plan, the person responsible for overseeing the project and business processes must keep a register of cases and requests and pressure those responsible for providing answers.
Look for someone detail-oriented, organized, and aggressive - not negatively, but productively. The project manager must be willing to escalate problems to the appropriate channels when necessary to resolve the issues and obstacles that, if not resolved, could lead to project failure. Thats the project management.
There was a list of the most popular it project management challenges and issues.