When Should An Agile Method Be Used In A Project?

When Should An Agile Method Be Used In A Project?

Agile has become very popular in the last few years. Its iterative and flexible approach is considered more and more suitable to manage information technology development projects in fast changing organizations.

There are multiple Agile software development methods that can be adopted, Extreme Programing (XP), SCRUM, Lean Development (LD) and Dynamic System Development Methodology (DSDM) are some of them. From those, SCRUM is the most popular and widely used. The Guide to the Project Management Body of Knowledge (PMBOK® Guide) includes Agile methods under the Project Lifecycle definition: “Adaptive life cycles are intended to respond to high level of change and ongoing stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually with a duration of 2 to 4 weeks) and are fixed in time and costs”. PMBOK ® Guide Fifth Edition, page 46.

When an Agile method should be applied to a project? In order to take that decision you may verify the following characteristics in your project:

Project size: Agile works better in small projects where you can provide small and punctual deliverables in very short periods of time in order to build gradually the final product. It is also good to use Agile in complex projects where the customer has difficulties to define the requirements or those are subject to change very frequently. You may also break a big project into smaller parts and apply Agile to manage those parts individually.

Customer / stakeholder’s availability: Agile requires high stakeholder engagement as deliverables are to be produced in very short periods of time covering multiple iterations. Stakeholders provide high-level input to produce those deliverables and they normally participate in the testing process. Collaboration between stakeholders is very important.

Project objectives and requirements: if requirements change frequently, Agile provides a flexible approach that let you prototype ideas to the customer in a fixed time-scale, allowing modifications to deliverables in each iteration. In an Agile approach requirements emerge gradually by constant feedback cycles and interaction among project participants.

Project team: in Agile, the team is empowered and self-organized to accomplish the tasks. They work in a truly cooperative environment where leaders collaborate with team members to produce the deliverables in an incremental way. It is important to take on account if the team is collocated or geographically dispersed in order to evaluate the organization and communications difficulties you may face.

Project estimation and planning: when using Agile the iterations are the planning units for your project. In every iteration, a set of activities related to certain deliverable(s) is completed. You may not get the deliverable(s) for that iteration totally correct, then you would refine them in the next iteration and so on. If planned deliverables cannot be completed within the specified iteration, functionality may be reduced or tasks may be rescheduled.

Project’s value for the Customer: verify with your client if the project results will add more value if they are accomplished incrementally, in small pieces or if his expectations will be fulfilled only when he can see a complete product.

Organization’s experience in Agile methodology: if your organization is new to Agile concepts it will take more time and effort to adopt those processes before you can apply them to a project. If that is your case, you may start talking about Agile and promote its use among your teams.

Some projects suit Agile more than others. For example. if your project’s main objective is to implement an ERP module where the supplier has a pre-defined process and detailed steps, it might be better to adopt a water fall approach. By contrast, if your project is related to a reporting system where multiple reports will serve diverse business units or it includes the deployment of a system that requires multiple iterations to be setup and tune, an Agile approach would work better.

In my next entry I’ll talk about the project manager role in Agile projects.

Are you using Agile already to manage your projects? Share your experience with us, we’ll be happy to hear from you.

What does make a project a success?

What does make a project a success?
I recently participated in a relatively small project that demonstrated to be a great success. Everything went so smooth from the beginning and through all phases until the implementation that I asked myself what made this project such a success? Why it was easy to move through the different stages without many issues?

Here the key success factors:

The Sponsor: this person had a profound need to get the problem solved as quickly as possible as the current situation was hurting the business in terms of cost, inefficiency and lack of control. His participation on the project was key as he motivated the Project Manager and the stakeholders to move forward with the selected solution. The sponsor played a very active role, demonstrating clear ownership, helping to drive decisions, defending the project at all times and supporting the Project Manager as needed. As an example, two stakeholders were against the proposed solution because they were not so keen to adapt to the change since they had the feeling of losing control when centralizing the information. The Sponsor stood up emphasizing the benefits this implementation will bring to the business such us reducing the compensation costs and improving customer satisfaction as everyone would have now access to the information allowing the easy identification of booking conflicts right in advance. Moving from templates in Excel to an automated centralized system represented a change that was good handled by training and proper communication. More information about on the Sponsor’s role can be found here.

The Project Manager (PM): this person set the right expectations from the very beginning. The PM sat down with the sponsor and key stakeholders to understand the goals of the project once he received the mandate to work on it. He kept the project scope under control, verifying changes before approving them, looking at the planning and its deviations and getting close communication with the project team and the sponsor. The PM executed continuous follow up on tasks and agreed actions, taking care that everything moves as planned while keeping open communication with the team. He shared good news as well as bad ones, controlling the risks and providing the information needed to reach a decision. Although some issues arose during the project he was able to manage them and get them timely sorted out. When the PM found out that the delivery and installation of the initial server budgeted for the project was going to be delayed for more than three months due to change on priorities, he quickly explored other alternatives with the Infrastructure team, fortunately an unused server was located and made available for the project in a record time and also representing a important reduce in costs.
Once the project was closed, the PM continued monitoring the deliveries to verify the expected benefits were reached while keeping contact with the stakeholders to check on additional needs to be covered which will derive in a new project.

The Project Team: The team was composed of 15 main stakeholders acting also as team members and 3 business owners located across Europe, Middle East Africa, with a Steering Committee of 6 participants. The fact that every team member would benefit of the results delivered by the project, influenced the level of commitment and engagement the team demonstrated along the project. The team motivation also played an important factor on getting things done; every team member had a clear understanding of his responsibilities and knew exactly how he contributed to the project’s objectives. The team was very excited as the project moved forward and they started to see the first results.

The Stakeholders: these people had a clear understanding of what the project intended to solve and the risks of not going ahead with it. They provided clear requirements, constraints and wishes which were properly balanced and covered by specified deliverables. Their level of satisfaction along the project and more importantly once results were achieved, they were in accordance with their initial expectations.

The Project Objectives: the project had clear objectives defined at the early start, describing what the project will deliver and the steps required to achieve them. These objectives were aligned with the organization strategy and agreed by stakeholders. These objectives let keep the project on course. Since requirements are never perfect and something is always required that was not envisioned initially, this project didn’t escape to that. Some stakeholders wanted to adapt the system 100% to the current process at their location; most of the project team stepped in, making sure the project remained aligned with the initial objectives and requirements, understanding the need expressed by those stakeholders and providing an alternative solution that was in sync with the original scope.

The Success Criteria: how success on the project is defined? How do we know the project has been completed? How success will be measured? Answers to these questions were provided at the very beginning of the project during the definition phase, getting the agreement of all stakeholders and assuring the project can deliver the expected results. Once the deliverables were completed they were measured against the success criteria before sign off. And during the project, the temptation to provide a bit more of what the customer was expecting was well controlled by the Project Manager, as that could go in detriment of the project schedule and/or budget. Having said that, those extra requirements were properly documented and kept for future enhancements of the solution.

All of the above contributed to this project’s success. Now we are getting prepared for the second phase of this project, which take in consideration such enhancements and other features discussed during the initial phase but left out of the scope mainly due time constraints. The story continues…

Related Posts:
Have You Ever Succeeded in a Project Without a Sponsor?

Have You Ever Succeeded in a Project Without a Sponsor?

How many times a Project Manager has had the feeling that he/she is the only one interested in keeping a project alive providing results? A Project Manager might deliver the desired results of a project without a Sponsor but that will cost him/her a lot of time, effort, mistakes, frustrations and perhaps also some enemies on the way. The absence or the inappropriate selection of a sponsor is one of the main reasons for a project to fail.

The sponsor role in a project is key for its success. But what’s a sponsor? Why is this role so important?

The sponsor is the person engaged and ultimate accountable for the project, who lives for the project, who will fight against the wind to get the project achieved its goals, who will get hurt if the project fails, who will push to get the resources needed to get the desired results and finally who will ensure the project remains viable and aligned with the company’s vision and strategies.

A Project Manager not only needs to have a sponsor, he/she ultimately needs the “right sponsor” for the project and not just a name to fill in the project organization chart. This is an active role that requires to be filled normally by a Senior Manager, closest to the project, interested on the project’s goals and with the time to dedicate to it. Ideally this person should have knowledge of Project Management practices, understanding not only the scope and outcomes of the project but also all deliverables and the Project Management documents that support it.

Having the right level of commitment from the Sponsor is also very important; the Sponsor should be there when problems/conflicts are originated and/or the Project Manager needs his/her support to move on with the planned activities as blockers are presented on the project development.

On the other hand, the Project Manager may not have all the information about the strategy and the vision of the company; this may cause project’s results getting into a wrong path.

Before accepting any mandate to start working on a project, always asks for a Project Sponsor; this will save you lot of troubles since the beginning and will let you set the right expectations upfront.