team members around a table, doing a puzzle together Perhaps the most important part of project management is that of control. Once the decision has been taken to launch and implement a project, the project manager must assume the responsibility for ensuring that each person involved completes their assigned tasks in order to thereby guarantee that the project runs according to plan.

The concept of project control is very simple: a project is created with certain targets after studying the resources available and drawing up a schedule to reach those goals. Control is what ensures oversight of these plans, ensuring that no team member deviates from the course set. The completion of control-related tasks will ensure achievement of the targets as they were defined in the planning stage.

After planning a project, it is recommended to implement a control system. The main requirement to begin with will be for the project to be fully defined and approved by the steering committee or shareholders’ meeting and, as appropriate, by the sponsor of the actions to be carried out.

These lines of action will indicate the costs, the scope for the project and the schedule to be followed for meeting the targets:

  • Cost base: this specifies the costs to be incurred by the project, with a distribution over time that will be coherent with completion of the tasks over time. This is very useful when wishing to compare estimates with actual cost.

  • Schedule base: a timeline with the targets set for each stage of the project will be created.

  • Scope base: formed by the various activities that comprise the project and that will enable the deliverables to be produced. All this is reflected in the WBS that was approved. The scope base allows the progress of each activity and each deliverable to be known.

Once these baselines are defined, it is time to get to work on project control. Of course, it is very important to consider certain factors when doing so.

  • Scope: This will control the tasks that should be carried out by each member of the project and that the result meets the requirements initially stipulated. Whenever a task fails to meet these requirements, it is considered as incomplete.

  • Deadline: Within project control, it is essential to monitor compliance with agreed deadlines. It should be noted at this point that the first schedule is drawn up without considering a margin for risks. This is because if these margins were to be considered at that point, they would end up being used to cover other issues that are not strictly considered as risks.

  • CostTwo factors require control in this regard: the total cost of the project and treasury control.

  • Risks: It is important to keep risks under control because, in the event of an unforeseen eventuality, this will have an immediate effect on the achievement of project targets.

Professional help for projectsBeing able to undertake large-scale projects and fully control them is a process that can sometimes prove rather complicated. It is therefore necessary to have software such as ITM Platform that incorporates the flexible management methods used by major corporations into your company. It is a great tool that will facilitate project implementation and delivery within established deadlines, and that offers advanced solutions to business.

Receive the latest blogs directly into your inbox

 

Keyboard key, fail, Thumb turned down

"The fastest way to succeed is to double your failure rate."

Thomas J. Watson Sr., Founder of IBM

While this quote is by no means dogma, nor a desirable way to obtain success, a plethora of companies have had to experience, and learn from, great failures. Finding and scrutinizing reasons for failure is a crucial part of the project management cycle. Here are three examples of the most disastrous project failures in history:

 

Keep under controlo all the components of your projects withITM Platform, try now for free!

Fail 1- Denver International Airport's Automated Baggage System

Who failed?

Denver International Airport (DIA), the largest airport in the United States by total land area, and the 6th busiest by passenger traffic.

What were they trying to achieve?

In 1991, DIA attempted to remodel and upgrade the arduous, time-consuming luggage check-in and transfer system. The idea involved bar-coded tags being fixed to each piece of luggage that went through 'Destination Coded Vehicles'. This would fully automate all baggage transfers, integrate all three terminals, and reduce aircraft turn-around time significantly.

Why did they fail?

We know that the five key variables all project managers have to deal with are scope, time, cost, quality, and risk. If each of these had a check box next to them, DIA would have a big, fat, red cross in every single one.

When DIA contracted BAE Systems to develop the automated baggage handling system, they completely ignored BAE's projected timelines, instead stubbornly sticking to their unrealistic 2-year schedule. The project was underscoped, and management took on unnecessary amounts of risk. Perhaps the most detrimental decision was to not include the airlines in the planning discussions. By omitting these key stakeholders, features catering to oversized luggage, sport/ski equipment racks, and separate maintenance tracks were not designed appropriately or at all.

Large portions of 'completed' works had to be redone, the airport opening was delayed by 16 months, and losses of approximately $2 billion were incurred. The entire project was scrapped in 2005.

Fail 2- The NHS' Civilian IT Project

Who Failed?
The National Health Service (NHS), England's publicly funded healthcare system, the largest and oldest in the world.

What were they trying to achieve?
The project aimed to revolutionise the way technology is used in the health sector by paving the way for electronic records, digital scanning and integrated IT systems across hospitals and community care. It would have been the largest civilian computer system in the world.

Why did they fail?

If you were to pinpoint the project's major downfall, you would need a lot of pins. Contractual wrangling plagued the NHS from the outset, with changing specifications, supplier disputes and technical problems pervasive throughout the project's doomed existence.

Unrealistic expectations of both timelines and costs were not helped by inadequate preliminary research, failure to conduct progress reviews, and a clear lack of leadership. The project has been referred to as the 'biggest IT failure ever seen' and 'a scandalous waste of taxpayers money'. Estimates of the damage inflicted upon British citizens fluctuate, currently hovering precariously around the £10billion mark.

While the benefit of hindsight elucidates how the politically motivated nature of the top-down project was never going to suit the localized needs of the NHS divisions, it is yet to be seen whether the ambitious project will ever be re-attempted.

Fail 3- IBM's Stretch Project

Who Failed?
International Business Machines Corporation (IBM), the multinational technology and consulting corporation that consistently lies in the upper echelons of global brand ranking lists.

What were they trying to achieve?

In the late 1950s IBM set out to design and build the world's fastest and most technically advanced computer, the IBM 7030 Stretch supercomputer. The computer would be 100 to 200 times the speed and performance level of its nearest competitor, thus 'stretching' the existing limits of computer design. This ambitious and impressive target resulted in its price being set at $13.5 million.

Why did they fail?

The project leader, Stephen W. Dunwell, later recalled that what made the project so complicated was that "many more things than ever before had to go on simultaneously in one computer." Engineers faced a conglomerate of challenges in designing and manufacturing many elements of the ground-breaking system; a load-sharing switch which would allow the use of transistors to drive the ferrite-core memory was amongst these problems.

The overly optimistic forecasts meant that project timelines and costs were severely overrun. Additionally, when the first working version of the Stretch was tested in the early 1960s, it was only 30 times faster than its predecessor. This was seen as a dismal failure, and the price of the systems that had already been ordered were cut to $7.78 million, below cost price.

There was a silver lining, however. The manufacturing, packaging, and architectural innovations Stretch had fostered were the cornerstone to many of IBM's future developments, and helped catapult them to the forefront of the industry. If such lofty expectations had not been set at the time, perhaps the project could have been a success. Alas, Stretch is resigned to the history books as being part of 'project management failure' lists such as this.

ITM Platform is a SaaS solution that simplifies planning, tracking, and collaboration among teams, alignment with business objectives and IT governance. This allows you to improve operations, reducing the time and costs of executing projects by 30%.

ITM Platform offers a SaaS solution that deploys more easily and with less risk in the market.

Try ITM Platform for free

Receive the latest blogs directly into your inbox

 

paper planes flying, forming a whirlpoolThe life cycle of a project comprises the set of phases into which a project is organized from start to finish. A phase is a set of inter-related project activities that generally concludes with delivery of a partial or complete product. Some simple projects only require one phase while other, more complicated projects require a significant number of phases and sub-phases.

ITM Platform allows you to reuse and adapt the most appropriate life cycles with project templates, try it now for free.

The life cycle of each project is defined by the phase model used in each case and this is usually determined by the organization, industry or even technology required for the project. It would be impossible to provide a generic description of the phases for all types of project. However, reference is sometimes made to a generic life cycle structure that consists of the following phases:

• Project Start

• Organization and Preparation

• Completion of Work

• Project Close

This generic life cycle structure should not be confused with the Project Management Process Groups defined in PMBOK. The generic structure of the project life cycle is a generic model relating to the organization of project phases and not the organization of processes established by the PMI. Neither should it be confused with the product life cycle on which the project is based. This is a generic life cycle model that can be used as a benchmark, especially when wishing to communicate project progress to people who are less accustomed to this type of management.

In practice, there is no one perfect way to organize phases for all types of project. Although some standard models exist in certain industries, projects can vary significantly between one another. Some projects will only have one single phase, while others may consist of two, three, four or even more.

Regardless of the number of phases within a project, they all possess similar characteristics:

• Each phase is focused on a specific task.

• Phases are usually aimed at producing a deliverable that must be available at the end of the phase

• The end of a phase closes with a review of the deliverable and sometimes with approval of that deliverable

Organizations and the various methodologies and industries have gradually defined more or less standard project life cycle models. This standardization is accompanied by the necessary adaptation by each team to each project. The life cycle greatly depends on the nature of the specific project and the style adopted by the project team or organization. To correctly manage the established standards and necessary adaptation to the specific needs of each project, organizations use such tools as ITM Platform to allow them to reuse and adapt the most suitable life cycles by using templates or base projects with specific project phase structures as a benchmark.

Try ITM Platform for free

Receive the latest blogs directly into your inbox

 

A board, people filling columns Stories, To do, In progress, Test, Done

Implementing agile methodologies (Scrum, Kanban or any of their variations) is a challenge faced by all kinds of organizations, project offices and managers. The advantages to be gained from this type of method for a great number of projects are clear, but actually implementing them is no simple task. At many organizations their implementation is often met with fear, rejection and obstacles. Here are a few keys to successfully implementing a agile methodology.

 

 

1. Start with the Right Project

It is actually possible to apply the agile methodologies to almost any type of project but the successful implementation of these methods does indeed require selecting the right projects to begin with, so as to achieve the maximum benefit in the shortest time.
Trying to apply agile methodologies to clearly predictive or classic projects does not usually lead to good results, as there is a considerable sense of losing control, with teams (and management) tending to revert to methods they already know. In contrast, experimental projects: presenting a lesser defined or highly changeable scope with multidisciplinary teams and needing swift results: provide an excellent opportunity for applying agile methodologies.

2. Clearly define the Team's Role

The role played by a team in classic or predictive projects is significantly different to their role in agile projects. The Project Manager plays a leading role in the former, with control over all aspects of the project, whereas the team has a much more relevant role in the latter and the Project Manager becomes a facilitator of the methodology. It is important to clearly define the team’s role in order to implement the method correctly.
An agile project requires a multidisciplinary, self-organized and self-managed team, which is a confidence challenge for many organizations that tend to apply managed and controlled methods. Understanding and building this type of team is very important. If you can build a team that consists of relationships between equals and a shared goal, a large portion of your future success will be guaranteed.

3. Estimation of Effort is still Key

One of the most common problems when implementing agile methodologies is believing that estimates no longer need to be made. Even though it is no longer necessary to make an estimate of the whole project and we can focus on the tasks for the next sprint or those with a higher priority in the product backlog, it is important to realistically estimate the efforts required for the tasks and ensure they are reasonably equal or that the size difference between them is clear.
If a task has not been completed at the end of a sprint or a task is constantly shown as “ongoing” in a Kanban project, it is very likely that we have made a mistake in our estimation that should be corrected, the task should be broken down into more manageable parts and our commitments should often be revised. Flexible management will ensure that the estimate focuses on the tasks providing the highest value or that we need to tackle most quickly. However, the estimation itself is still important.

4. Know and control Limitations

Agile methodologies have limitations and they must be taken into consideration. There are scope, deadline, cost and quality factors that need to be met. It is true that priorities might be inverted or the scope might be more negotiable, but the limitations on deadline, cost and quality remain and must be managed.
These methods state that tasks should not exceed a certain effort, define a maximum Work in Progress (WIP) we can manage or establish a time-box by using sprints. Limitations must be strictly maintained and not changed lightly, as they are a very important part of their model. If we make changes or adjustments and accept all types of changes, we are losing control.

5. Manage tension

Although it might seem contradictory, agile methodologies are more like a long-distance race than a sprint. Some organizations approach these methods as a way of moving more quickly - getting more done in less time – taking advantage of the fact that teams are more deeply involved. This is true, but if we want the implementation of these methods to last, we must manage team tension.
Having a motivated, results-focused, self-managed and efficient team is possible with agile methodology. In order for these characteristics to last over time, we need to ensure that the team also perceives an improvement to productivity and not only a constant increase in effort and workload.

6. Metrics: “power without control is useless”

These methods are extremely powerful. They are capable of producing motivated teams that obtain impressive results in genuinely short spaces of time. Nonetheless, all this power does not come at odds with control. Agile methodologies encourage us to measure, analyze and constantly improve.

Metrics are the way to explicit project management based on real data rather than intuition, opinions or occasional emergencies. Speed, flow and commitment compliance are all key metrics that we should gather and analyze in order to streamline our processes and improve our teams.

7. Quality, Quality and… Quality

Quality means repeat business. Increasing delivery speeds, managing estimates incrementally or having a self-managed team do not mean setting quality aside. It is very important to deliver products quickly in agile methodologies but those products should also work; they need to do what is required of them efficiently.

That is why it’s important not to leave quality until the end and incorporate aspects of quality validation, revision and measurement of all the items, deliverables and products we generate during the project from the outset.

8. Remain to the methodology rigorously

Agile methodologies have few rules, standards or products. It is important to follow the method precisely, especially at the start. It is better to change nothing (or almost nothing) before gaining experience. If something seems strange, have a little patience and give it a chance.
Scrum methods establish a series of roles, meetings and stages that should be preserved, experienced and maintained in order for these methods to truly work as we expect. It is possible to go from less to more in these methods, but follow their instructions precisely until you are comfortable with their use.

9. Revise and adjust the method

As soon as we have advanced significantly in the use of agile methodologies, we can consider making adjustments to them. It is important to conduct reviews or retrospective exercises that allow you to see what does and doesn’t work within your organization and make the necessary changes to adapt the method to your culture, style and requirements. However, this should always be done after having tried the standard models.

Agile methodologies are indeed flexible, very flexible, and that is why they can be adapted to almost any type of project, organization or team. With a little experience, possible imbalances can be identified and changes, adaptations or additions can be made to these methods so as to ensure they perfectly suit our needs and circumstances.

10. Maximize visibility

One of the most important keys to the success of agile methodologies is visibility. Implementing these methods is done “behind the scenes” at some organizations, almost invisibly or as if applying this type of tool were embarrassing in some way. It is important for this type of implementation to be made visible, open and public so that the entire organization can see what is being done, how it is being done and what has been achieved by doing it.
Avoid using private "Kanban" methods or hiding them when the project client or sponsor appears. Be brave and show, explain and harness the most visible advantages. There is no better ally than a project client or sponsor that is involved in management, added to which agile methodologies enable maximum visibility and maximum participation from all stakeholders. An agile methodology is not an exception or an extravagance from an isolated team but something that can be applied throughout the organization.

11. Manage expectations

Many teams and organizations that embark down this path believe that all their problems will be solved as if by magic; that the client will never change their mind, that products will no longer have defects or that nothing “unpleasant” will ever happen during the project again. Agile methodologies adapt very well to changing and stressful environments but they are not the solution to every problem. Managing expectations from teams, clients and management is important to successful implementation.

The method may well not be perfect the first time around, that teams will feel uncomfortable with certain aspects of the method or that the project will encounter certain problems. This is completely normal. You will quickly see that progress is being achieved, that progress is significant and that the results are very positive.

12. Select the right tools

Using a support tool when applying agile methodologies facilitates their implementation at organizations. Having centralized support for sharing information, measuring progress and maintaining project control is highly important. With the right tool, teams will be able to work independently while the organization can maintain control over project progress, costs and revenue, efforts, etc.

Do not be fooled by tools that are free but completely disconnected from the rest of your organization. Agile methodologies are not an anecdotal or exceptional process implemented by teams with highly unprofessional tools; it is an important decision by the organization to adapt and improve. We are facing a project management revolution that is allowing us - with the right tools - to improve our performance, deliver high-value products very quickly and achieve great success.

 

Receive the latest blogs directly into your inbox

 

post-it in columns on a dashboardAs we have seen, the project life cycle comprises the set of phases into which a project is organized. Depending on the organization in question and any overlapping between phases, various types of project life cycle can be defined: predictive or classic life cycles define the product and deliverables at the start of the project; iterative or incremental life cycles adopt an approach that gradually increases or expands the product in steps; and adaptive or flexible life cycles develop the product through numerous iterations, with the scope for each iteration only defined at the start thereof.

Try managing classic, iterative and flexible project life cycles in ITM Platform

Predictive, classic or planning-focused life cycles

Predictive life cycles (also known as classic or planning-focused life cycles) are those in which the scope, deadline and cost are determined as soon as possible in the project life cycle and efforts are focused on meeting the commitments established for each one of these factors.
These projects are normally organized into a series of sequential or consecutive phases, where each one is focused on a specific sub-product or activity. Normally, the work undertaken in one phase is very different to all the rest and so the project team will vary according to the phase under way at any given time.
From the start, project management focuses on defining the scope and drawing up a detailed plan of the necessary activities. From there, work is focused on following the plan. Any project scope change must be managed explicitly and usually leads to a review of the plan and formal acceptance of the new plan.
Predictive life cycles are chosen when the product to be delivered is well-defined and relatively extensive knowledge exists on how to build the product. This has traditionally been the most common work model but does not necessarily suit the circumstances of all projects and organisations.

Iterative or incremental life cycles

Iterative or incremental life cycles are those in which the activities of the project are repeated in phases or iterations and understanding of the product by the project team increases in each one. The iterations develop the product through a series of repeated cycles that successively add functionality to the product.
At the end of each iteration, a deliverable or set of deliverables will have been produced. Future iterations may improve said deliverables or create new ones. The final product will be the accumulation of functionalities built up during the various iterations.
Iterative or incremental life cycles are chosen when it is necessary to manage vague objectives or considerable complexity, or when the partial delivery of the product is key to success. This type of life cycle enables the project team to incorporate feedback and gradually increase the experience of the team during the course of the project.

Try ITM Platform for free

Adaptive or flexible life cycles

Adaptive life cycles, also known as change-focused methods or flexible methods, respond to high levels of change and to ongoing participation by the interested parties.
There are two basic models for this type of life cycle, those focused on the flow (for example, Kanban) and others focused on iterative and incremental cycles (for example, Scrum). Very clear limitations are set on the concurrence of activities (Work in Progress) for the former and on very rapid iterations (between 1 and 4 weeks) in which the work is done for the latter (Sprint).
In flexible models, the overall scope of the project will usually be broken down into a set of requirements or projects to be undertaken (sometimes called Product Backlog). At the start of an iteration, the team defines the functionalities to be tackled in that cycle. At the end of each iteration, the product should be ready for review by the client. This type of life cycle requires teams to be highly involved and the sponsor or client to provide constant feedback.
Generally-speaking, flexible methods are chosen in environments that change swiftly, when the scope is unclear or when the value contribution is highly variable and with highly involved teams.

Receive the latest blogs directly into your inbox