Archive

Archive for the ‘Success Rate’ Category

10 Reasons to Doubt Your Agile Transition Has Been Successful

August 26th, 2009 Martin Proulx 1 comment
  1. Every time product requirements change, you hear a tree fall in the forest in order to support the printing of a new multi-page gantt chart;
  2. The project managers comes into the office early in the morning so he can carefully prepare the specific tasks to assign to each team member;
  3. Although sitting within 20 feet of each other, your team members proudly sit in closed offices and only communicate via email;
  4. Your business analyst is pleased to show you that she managed to fit each user story on 42 50 index cards;
  5. The last time a business representative attended your requirement gathering meeting, she was using a Palm Pilot;
  6. As per the project plan, the Champagne has been opened to celebrate the launch of the project while half the development team is busy trying to do code integration;
  7. While no team members attended, the management team is pleased with the content of the discussions that took place during the end of release post-mortem (retrospection);
  8. The architects have locked themselves up for 6 to 8 weeks in order to properly prepare for the upcoming project;
  9. The business representative is waiting for her administrative assistant to arrive in order to take notes from the daily stand up meeting;
  10. A project control officer has been assigned to the project to ensure each steps have been properly documented and successfully executed.

Do you have other reasons to doubt?

  • Share/Bookmark

Less projects were reported to be successful in 2008

May 11th, 2009 Martin Proulx 2 comments

The Standish Group released the most recent version of the Chaos Summary Report 2009 on April 23rd and the results are worst than last year with only 32% of all projects surveyed were reported to be successful (down from 35% in 2006).In the context of this survey, a project is defined to be successful if it was delivered on time, on budget and with the required features.

Chaos Summary Report 2009

Chaos Summary Report 2009

Along the same lines, 44% of the projects were challenged (did not meat one or many of the success criteria) while 24% totally failed. The Standish Group highlights that costs overrun 54% (+7%) and time overrun 79% (+7%) both went up compared to the 2006 results.

The reports also explains that the probability of success greatly decreases as the size of the project increases where projects costing less than $750,000 have 61% success rate while projects costing over $10 million only have 2% success rate.

The second part of the report present the 10 Laws of Chaos and while the report doesn’t make any correlation between these laws and the Agile principles, it is easy to make some correlations.

  1. Law of the Two Faces: Successful projects include business-knowledgeable users with good communication skills.
  2. Cheetah’s Law: Swift decisions are typically better than long, drawn-out analysis.
  3. Law of the Roads: Clarity and focus are essential to a successful project.
  4. Law of the Five Deadly Sins: It is how you deal with each of these sins that will determine the success or failure of your project.
  5. Law of the Long-Tailed Monster: Over- and under-building applications represents the biggest form of software development waste.
  6. Law of the Edible Elephant: Software should be built in small, iterative steps with small, focused teams.
  7. Law of the Mad Hatter: Complexity causes confusion and cost.
  8. Law of the Empty Chair: Keep the project cycles short with continuous deliverable.
  9. Panda’s Law: Inaction is the purest form of failure.
  10. Law of the Fools: It is not just having the right tools but the skill to use them that make all the difference.

Can you draw the parallels with the Agile principles?

  • Share/Bookmark

We have a huge budget and too much time to complete our business intelligence (BI) project

April 27th, 2009 Martin Proulx No comments

If you agree with the title of this post then you don’t need to read further, either your business intelligence (BI) project will be amongst the very few (less than 40%) that will not end in abandonment / failure or you do not have to worry that your project will drain your huge budget before slowly and gradually failing.

For everyone else, this article that presents the benefits of using an Agile approach to software development. This post is a follow up to my previous article called Nobody is interested in Agile where I wondered why so few articles explained the actual benefits (the WHY) behind Agile.

Why should organizations use an Agile approach for their Business (BI) Intelligence projects?

In clear business terms, using an Agile approach for the development of your BI solution will greatly increase your return on investment (ROI). Before reading further, you need to keep in mind that Agile will not address all of your software development issues but by empowering the people who are directly and indirectly part of your project team and by taking a pragmatic and realistic approach to the software development process, the implementation of Agile principles within your organization will address the most critical problems typically encountered by a software development project.

The following diagram summarizes the 7 key benefits of implementing an Agile approach for your business intelligence project. Each of the benefit is explained further below.

 

increased return on investment by using an agile approach

increased return on investment by using an agile approach

 

The intent of this post is not to describe the Agile principles nor to explain which practice should be applied in a specific context but to describe in clear business terms the benefits derived from these practices.

Increasing Productivity

The throughput of your development team will greatly increase once you implement agile methods. The associated benefits:

  • Streamlined and improved face-to-face communications;
  • Continuous performance improvement by retrospecting at the end of each short iteration;
  • Progress is not measure by looking at compliance to a project plan but by evaluating by the quality of the output;
  • Project management is shared by everyone on the team instead as the team self-manages and becomes fully accountable for the results and reporting mechanisms;
  • Use of proven and innovative software engineering practices greatly improves quality;
  • Increased ability to estimate efforts and time lines;
  • Team productivity can be assessed and monitored over time which provides a predictable rhythm.

Meeting Time Commitments

Project time lines are typically very critical and as such implementing an Agile approach help meet time commitments.

  • Reduce the overall scope into small manageable chunks and maintain focus on short term delivery instead of the final end date;
  • Make the team’s progress visible to everyone with the use of defined reporting (burn down chart);
  • Team has to demo working product at the end of each iteration;
  • Estimating and scheduling is a collaborative process shared between the customer and the project team;
  • Frequent delivery of software reduces the overhead of moving the application into production;
  • End users are involved in defining the time lines instead of leaving the activity to the development team.

Increasing Quality

Quality is never negotiable so implementing Agile is beneficial to the project team.

  • Team has to demo working product at the end of each iteration;
  • Early detection and fixing of faulty components;
  • Testing is not only done at the end of the project when the cost of fixing issues is much greater;
  • Tests may be written before the development cycle begins and must be continuously be run throughout the duration of the project instead of waiting until the end.

Delivering on Requirements

Many projects are delivered without meeting the expectations of the customer. Using an Agile approach helps the team deliver on the requirements.

  • Customer is part of the project team, defines the priorities and assesses the end results;
  • Obtain continuous feedback throughout the development cycle and not only at the end;
  • Team will deliver on the original requirements but if there are requirement changes, the team will provide opportunities for feedback and adapt to meet the changing requirements;
  • Analysis and design is done at the beginning of each iteration and not only at the beginning of the project;
  • Software should meet the current needs, not the needs that were defined months before.

Delivering Business Value

As opposed to emphasizing tools and processes, Agile focuses on delivering value to the organization.

  • Teams work on value added tasks (as opposed to paper work and attending meetings);
  • Teams delivers the highest value features first and avoid building components that will never be used by the customer;
  • Focus on results (as opposed to process oriented or project plan driven);
  • Time boxed to ensure compliance to defined time lines;
  • Costs and benefits can be associated directly with the pieces of software being delivered, if the estimated cost for a component is greater than the anticipated value the component may not be developed;
  • Reduces or eliminates non-critical activities;
  • Raising issues and impediments early in the process reduces the cost of fixing them later on.

Improving Knowledge Sharing

As Agile relies on the concept of the team as opposed to the individual, knowledge sharing is a direct benefit.

  • Prevents the fact that a single individual becomes the bottleneck for the project by emphasizing sharing of information and tasks amongst the team members.

Increasing Employee Satisfaction

Although not frequently mentioned, employee satisfaction is an important benefit of implementing Agile.

  • Relationship between the project team and the customer are improved by developing trust and sharing knowledge throughout the duration of the project;
  • Team self-organization and autonomy greatly improve team members’ morale;
  • By inspecting and adapting their work processes, the team members grow their skills and motivation;
  • Given the opportunity to play various roles on the development team, individuals increase their satisfaction by developing new skills.

As I mentioned in my previous post, there were very few articles that explained the benefits (the WHY) of implementing an Agile approach for software development project. Hopefully, this post will help you promote agility within your organization.

  • Share/Bookmark

You have the best BI application. Great! Do your users know?

April 10th, 2009 Martin Proulx No comments

Your organization has invested large sums in the development of a Business Intelligence (BI) program. The project team followed an innovative approach by combining SCRUM as their project management methodology with AGILE software development practices including some advanced software engineering techniques such as test-driven development (TDD), re factoring and continuous integration. The project was delivered on time and within schedule. The team is happy, the Scrum Master is delighted and the Product Owner (PO) invited the whole team for a memorable dinner. Everything went perfectly …

Actually, no. Probably not! Besides the PO are all the users aware of your project?

I would like to offer some communication strategies that could possibly help your project success rate.

  • Ask the users participating in the project to spread the good news by infecting other members of their department relative to the benefits of the new application.
  • Provide frequent demonstrations of your new BI application to a broad audience to demonstrate the usability of the application and the benefits of the new tool.
  • Run an internal advertising campaign with visual media (brochures, posters, mugs, etc.). The aim is to generate curiosity with relation to the new application.
  • Conduct formal and structured presentations to teams and individuals impacted by the new application to answer their questions.
  • Use the project sponsor or the PO to disseminate the information about the project and to demonstrate the value of the new application.

In summary, use the project team members to communicate frequently and to as many people as possible. Be enthusiastic and repeat the process.

I must admit, that the list of communication strategies is not exhaustive but this was not my goal. Communication strategies will vary depending on the organizational context. Strategies that have worked well in one organization may not be applicable to another. My objective was simply to remind the project team to plan and execute their communication strategy as soon as possible. The lack of communication may not only delay the adoption of the new BI application but in the worst cases this could lead to the potential rejection of the new solution.

A good communication strategy will increase the chances of success of your new business intelligence application.

  • Share/Bookmark