Winning with “Project SD”
Every team needs a process they can embrace because they know that process will get them to the desired result.
This week we welcome guest blogger, Greg Shade, Principal & Program Manager at Mercer Human Resource Consulting. Greg’s story is about a team on a journey to become a more trustworthy partner to the business, capable of delivering great products within the bounds of all expectations. Greg’s insights on how his team built trust between the IT folks building the product and the business/user communities using it, is both informative and inspiring.
Send us your comments on how Greg’s ideas can help improve relationships with the business in your organization.
The Background
The SD team has recently completed its fifth release of software on time, on budget and on scope. The team is performing at very high levels and working very well with its business partners. While it still has areas for improvement, it appears that the team has found the “secret sauce” and is “firing on all cylinders”.
This post describes, from the author’s perspective, what is behind this success and how it may be leveraged and/or improved.
History
The SD 1.0 product was deployed to production in the 3rd quarter of 2010. It was an ambitious project using a new platform and the latest development technology. The release did not meet the target for its deploy date, budget or quality measures. There was much finger pointing as to the cause of the failures. The resulting relationship between the business and technology teams had degraded to what can be described as “toxic”.
Where We are at Today
Since version 1.0 was deployed, “everything has changed”. There has been a revamping of resources at all levels. The planning, estimating and execution processes have been reengineered. New members have joined the team and the relationships with the business partners have been restored. All this has been instrumental in setting up the team for success. Why is the SD team winning today?
The SD team is winning because it has built and maintained trust with its customers by establishing and following three simple rules:
- Define what will be delivered and when.
- Deliver – on time, on budget, with high quality.
- Be flexible.
Sounds simple enough, but how does a team successfully accomplish this?
Define what will be delivered and when
This is where the SD team’s success started. The team uses the “Getting Predictable” planning model along with “Rigorous Hard Conversations” to accurately define project scope and timeline.
The “Getting Predictable” model allows the business and technology teams to begin with business concepts, then define Business Process Scenarios (BPSs), estimate the effort using an Interface Catalog (IFC) and then build a “bet your paycheck” release plan. From this plan the project costs can be accurately developed and all approvals can be attained. All this is done BEFORE business requirements are developed by the Business Analyst (BA) team. It sounds counter intuitive to “bet my paycheck” on a plan before requirements are developed, but it works if it is coupled with the “Rigorous Hard Conversations” and a strong trusting business partner. Let me explain.
The SD team has a strong trusting partnership in its Business Product Manager. But this was not always the case. Remember, he was a member of the “toxic” relationship not too long ago. How did this change? The team adopted a mantra of “Either we ALL succeed together or we ALL fail together” and they practiced that mantra.
To this end, the Business Product Manager was invited into the detail planning effort using the Getting Predictable method. He sat in conference rooms for days and weeks as the tech team analyzed and estimated the project scope while building the IFC. He grew to appreciate the effort and expertise that went into the estimates for the different product features. In short, he gained trust in the team: If the team said it would take two weeks, it would take two weeks because he saw all the thought and work that went into those estimates.
This detailed understanding allowed the team to have productive “Rigorous Hard Conversations” with the Product Manager, with everyone agreeing that 10 pounds of stuff cannot fit into a five pound bag; it’s just physics. This set the team up for joint problem solving when defining feature scope. It allowed the tech team to become true trusted partners with the business, explore options and propose solutions. It allowed the team to be realistic about capacity and accurately define what could be delivered and when.
Deliver – on time, on budget, with high quality
This is where the SD team’s credibility is built along with its system.
The SD team uses an iterative Waterfall method or a Wet/Agile approach. The overall project is broken into feature blocks which can be completed in iterations of approximately six weeks. These feature blocks are tested by QA and demoed to the business team. Completed feature blocks are collected until the end of the project at which time the system is completely regression tested and then deployed to production. The processes and techniques used by the team are solid, modern, IT development techniques. The project management of the development activity is lean but allows the team to accurately monitor progress and spot any trouble issues as they occur.
The SD team is executing successfully in this area due to the strong leadership in place in the different disciplines. The leaders are seasoned professionals who have “bet their paycheck” and are 100% committed to meeting the business needs of their customers. Throughout the project, the members work together as a team and practice their mantra of “either we ALL succeed together or we ALL fail together”. When problems arise the team brainstorms and troubleshoots together. Solutions are owned by the group and ego is not much of a factor. They take pride in their work and the finished product.
Be Flexible
The SD team is flexible in two areas: First, the release schedule includes some “unallocated time” to be able to absorb small change requests that are common in any development project. Secondly, the team is flexible in working with product management when significant change requests arise. Together they explore alternatives and come up with a mutually agreeable solution.
For example, if a new feature block is requested to be included in the release, the team will consult with product management and identify alternatives. This involves creativity on the development team’s part as well as “Rigorous Hard Conversations”. Many times adding a new feature block means “horse trading” or not doing another previously agreed to feature in exchange. The team endeavors to accommodate new requests while at the same time being realistic in what can and cannot be accomplished. This is made possible because of the trust that exists between the team and the product management.
Making Great Things Happen
Many processes, practices, and people go into making the SD team successful. They are all important but when they are joined with trusting relationships and solid teamwork, synergy begins to take hold and great things begin to happen. In the end, the SD team is winning by producing innovative products for its customers.
Category: Business-IT Alignment, For Practitioners, Team Dynamics, Team Performance