You Guys Start, We’ll Figure This Out Later
We’ve all experienced a project that is kicked off just a bit sooner than maybe it should. You know this because you hear those infamous words:
“You Guys Start,
We’ll Figure This Out Later.”
Consider this simple phrase a warning sign that your project is in danger before you even start. The business team is still trying to figure out what they need. Yeah, they know their problem is clear but the solution is anything but.
So what’s behind this all too familiar call for help?
Lack of Alignment.
What the business is really saying:
“You Guys Start and We’ll Get Aligned. Right Now We Can’t Agree.”
This lack of alignment is almost always due to the business stakeholders’ struggling to determine and agree on what “success” is. This can apply to a product implementation, customer software development or even a change in business processes.
Some disagreements can be on the large scale:
Should our first release of tax planning software only focus on Federal tax strategies or must it support State tax planning too? If it should, which State? All 50? Isn’t that going to take forever?
Should we develop a full suite of open source Office type products including a word processor, spreadsheet, Powerpoint like tool? Or should we simply focus on our core offering, the presentation tools?
Some disagreements appear less strategic:
Does the solution have to support our customers in four countries and be localized in six languages? Or can the first release simply support our current client base?
Should our solution include a Spellchecker for the medical terms that we will collect in our survey tool?
“You Guys Start, We’ll Figure This Out Later” = Less Than Successful Project
In spite of this warning, the project needs to start. So we begin our planning and whenever possible, hedge our design to accommodate change. But, in the end, how likely is it that we deliver what they, the un-aligned business stakeholders, fuzzily define as success?
More often than not, they never get aligned. And if a new business person gets involved, who knows what their view of success is. At the end of the day, we are responsible for a potential “less than successful project”. Hmmm – they may even call it a failure!
And this shouldn’t surprise us! In fact, if you hear the words “You guys start…”, that should be a predictive flag that you may be setup for failure.
The message is clear: The Business needs to own the risk of having an I.T. team start without alignment among the Business. And the Business along with I.T., needs to jointly own and collaborate on how I.T. will re-plan once the business has completed their work by finally agreeing on what is project “success”.
What About Agile?
When I share these ideas with colleagues, I typically get two reactions. The first includes smirks and smiles saying: “Yep – we’ve heard that and you are right, it is painful.”
The second reaction comes as a challenge: “Wait – isn’t that what Iterative development is all about? The business can plan and change direction with every iteration?”
The assumption is that Iterative methodologies such as Scrum or Agile, can be an effective way to solve nonalignment situations. They break up a project into small durations (iterations) that focus on specific feature sets. An iteration may be as small as a week, but may be defined as large as four weeks. (You’d be surprised at how much energy this last point generates.)
This is often considered a safe/natural solution because at the beginning of each iteration, the business will look at the list of everything they want and define the target features they would like the team to work on for the next iteration(s). This re-planning allows the business to change its mind and adapt based on feedback and potentially changing business conditions.
An Iterative process doesn’t resolve alignment issues!
But we still have a problem here: The Business Stakeholder who kicks off each iteration is now accountable to determine what “success” is for that iteration. If they aren’t aligned with the original/other stakeholders, then they are actually steering the ship off-course. And there is NO visibility. The rest of the stakeholders may not even know what decisions and tradeoffs have been made within an iteration planning meeting.
But wait Bob! When we do an Agile project, we always have all stakeholders in the loop about which features were completed and what will be planned for the next iteration!
And to that I say: You are not the norm! So congrats!
When most organizations embrace Agile, they are focused on the core I.T. team, planning and execution. They don’t have a model for how this changes the behavior of the business stakeholders in their planning and management of initiatives.
True, we tell the business folks we want them in the room with us, giving us quick feedback, etc. But what we often don’t do is explain to them that this level of feedback requires them to constantly re-baseline what features are “in and out” based on their goals and budgets. There is no formal process for shifting this ownership over to the business.
So what’s the point?
ITERATIVE ALIGNMENT
The fact is that more often than not, a project will be started after hearing: “You Guys Start, We’ll Figure This Out Later”. It is the nature of business and politics. In fact, as I illustrated above, our iterative processes can almost “enable” a lack of alignment.
It’s important for us to set goals for the business to do regular “alignment-check-in”. We need to make sure the business owns and is accountable for understanding what they are asking for, and what changes have been made.
We should strive to eliminate the surprises at the end of a project where a business stakeholder asks:
- Where did this feature come from? or
- Why is this functionality missing?
Even if we followed the requirements to the letter.
So what do you think? Do you disagree? If you agree, who do you think should be accountable for managing this within your team? Within the business?
Category: Business-IT Alignment, Defining Success, For Practitioners, Team Performance