You can rescue a failing IT project

If you work in the IT world, you’ve probably seen projects that have come off the rails and require a major course correction to get back on track. In this blog post, I will highlight the warning signs of a failing project from a recent client, along with the process we follow to get critical initiatives back on track.

Danger ahead!

This client was replacing an important legacy system as part of a long-term modernization program. The project had been in danger from the start:

  • High IT team turnover rate led to new hires that didn’t know the business
  • No strong project management on the team
  • Selected this project to initiate an Agile development approach
  • No Product Owner to represent the needs of the business

After two years only one major module had been delivered and the updated project timeline was three times longer than the original schedule. The alarming and unexpected extension of the timeline was the motivation our client needed to contact Edgewater for help.

Project Assessment

Our first step was to conduct an assessment of the project to better understand:

  • Major risks
  • Staffing and capabilities
  • The estimation approach
  • User involvement
  • Agile adoption

In this case, the findings clearly indicated a project at a high risk of failure.

Recommendations

Given the determination of “high risk”, Edgewater recommended some bold changes:

  • Establishing a realistic project schedule with achievable milestones
  • Hiring a full-time Product Owner to lead the requirements effort and build the backlog
  • Doubling the size of the IT development team to increase productivity and reduce the timeline
  • Using a blended team of full-time resources and consultants
  • Adding a full-time Project Manager/Scrum Master to lead the Agile development team, keep the project on schedule, and provide reporting to senior management

Initial results

After the first six months, the results are very promising:Productivity-for-PR

  • The project timeline has been cut in half
  • The development team has increased productivity by over 50% and has delivered modules on schedule
  • The requirements backlog has doubled
  • The client IT team is learning best practices so they will be able to support and enhance the system on their own
  • The Project Manager is mentoring the team on Agile roles and responsibilities, and managing the development team

Our client is extremely happy with the productivity improvements, and the users are excited to work on this project.  There’s still a long way to go, but the project rescue has been a success.

To learn more, watch our video then contact kparks@edgewater.com.

Does your PMO get in the way of your Agile Development Teams?

Do your agile teams have your PMO pulling their collective hair out in frustration?

A family in harmony will prosper in everything. ~ Chinese Proverb

Does this sound familiar:

We value face-to-face conversation We need formal, written documents
Working software is our primary measure of progress Where is your status report?
How are you progressing against your project plan?
Self-Organizing Teams Defined Roles and Responsibilities
Individuals and Interactions Processes and Tools
Respond to Change Follow a Plan
Culture of Change Culture of Order

You’ve embraced an agile development methodology, empowered your teams, and they are eager to move forward.  They want to deliver a quality product to the organization as quickly as possible.  They want to add value and make a difference.

Your project management office (PMO) understands and supports the agile development approach, but they still need to manage the overall project portfolio and they want to be sure that the agile teams deliver in alignment with the organization’s strategic objectives.  They want to add value and make a difference.

Both groups have the organization’s best interests in mind, but there is a definite culture clash.

Agile teams can be dismissive of the PMO. Their approach is different, they don’t need to worry about those processes and frameworks; they just need to focus on their own project.  The PMO should get out of their way.  It reminds me of a teenager who wants their parents to just leave them alone – until the parent is needed.

PMOs can act like a dictatorial parent.  They can demand process and procedure from agile teams because that is what they’ve always done.  But process and procedure that doesn’t add value does get in the way.

Both groups need to respect each other and adapt.

Just like the parent of a teenager, the PMO should be loosening the rules and allowing greater freedom while demanding accountability (and standing by with a safety net). The PMO has to adapt itself to the agile world,  working with the agile teams to understand the tools that they are using to manage and control the agile project.  It should adapt these tools to their use rather than making the agile team use the same old PMO provided reports and templates.

The agile team, like the teenager, also needs to acknowledge and respect the role of the PMO.  The project and the project team aren’t operating in a vacuum.  It needs to fit into the larger organizational plan and processes.  So the agile team needs to fit itself into the framework that the PMO has established.  That may mean complying with certain project checkpoints or processes, such as conducting a formal risk analysis or establishing a milestone-level, project plan, budget, and scope.

If each can recognize that the other is not purposely trying to obstruct them and understand the value of the other to the organization, they should be able to leverage on another’s strengths.  While there may still be friction and areas of disagreement, the end result should be a set of processes that improve project outcomes and ensure alignment with overall organizational objectives.

Avoiding Agile Anarchy

Agile project management

Conventional Agile Methodology Wisdom lists three factors that define an Agile-ready project:

  1. High Uniqueness
  2. High Complexity
  3. Aggressive Deadlines

After using these three parameters to select your first agile project, there is still legwork to be done before sprints are humming along.

Many agile initiatives are announced by fiat with the team structure, sprint length and other basic rules of the road mandated by the Agile Initiative Sponsor. They dive right into development sprints, gathering user stories along the way to build a backlog. Here are some ways this approach could backfire:

  • In a rigid, hierarchical organization, the ability of teams to self-organize is often historically non-existent, and the change management hurdle might be a gap too big to jump. There are many ways that interoffice personalities and politics can sink an agile initiative in its early stages, or at any point along the way.
  • Complex, unique projects require some upfront work on architecture before the development sprints can begin. Agile teams can best manage this by making the first few sprints architecture sprints. Time and again, we have seen horror stories when the overall design or architecture is glossed over:
    • Parallel agile teams within a business design disparate UI’s to enable functionality that is essentially the same, but serves the needs of one particular product group. Before long, it’s obvious that external stakeholders are confused and put off by having to remember two different ways of interacting with the same company
    • User stories are taken down as the basis for development sprints, but they fail to consider the secondary stakeholders. BI reporting needs are often missed.
    • Prioritization of the backlog is driven by business need, without any attention to building foundational pieces first, then layering on transactions.

In short, Agile without Architecture leads to Anarchy, and a lasting bad impression that will taint future Agile efforts. It’s best to look before you leap and take time to address any Agile readiness gaps.