Software projects need to begin with a shared vision between the business team and the IT team. The business understands why the software needs to be built and the IT team understands how it should be built. If the two teams are out of sync, the when and how will be greatly impacted and result in project failures.
Below are the proven ways of handling Out-of-Sync stakeholders problem
Clearly Articulate the goals
To prevent feeling of out of sync throughout your software project, take a few minutes at the start of your project to create a common vision through clearly articulated goals. This does not mean you need to have every detail explained, but a quarterback needs to know where the receiver will be before they get there.
However, you don’t need to distribute your business plan as required reading for all team members. Often, that level of information would lose meaning with people that aren’t performing that part of the plan. Show them what they need to own and the pieces they are connected to prior to the start of the project and craft a list of a few topline goals for why what they are doing is important. They can start with “we are building this software to . . .” or “we are adding 3 features to our product in order to x, y, and z.”
Keep the wording clear and simple. Write out the major goals and post them in a central location. As leaders of the project, you need to use these goals both to maintain a common vision and to reduce confusion. Constructive debate will happen throughout the project as team members make suggestions and work toward those goals.
When team members make individual contributions to those goals, they will use these goals to verify they are in line with the bigger vision. Taking an extra few minutes to ask, “Does this help us reach our goal?” can save rework time later, help keep the project on plan, and get the best thinking and efforts of everyone involved.
Language shapes our world
An old adage states we should “say what we mean and mean what we say”. This holds true for software projects, but it is not always easy. Language is not very good at explaining concepts.
Life experience shapes how we perceive the world and that perception alters our interpretation of various words. When two people look at a color and say its name, that answer will depend on how deep their past is related to colors as well as how their eyes and brain function at color perception. Your project has many of the same challenges.
- Shared Words. Because words can have various meanings, make sure you take nothing for granted. Your version of red may be maroon to me. Consider creating a glossary of words and their definitions that include both commonly used business and technology words as they relate to this project.
- Templates. Commitments in a software project need to be measurable and actionable. Saying you are “working on it today” does not produce an outcome but rather informs the receiver of how you are spending your time. In a project, what is important is when you will have that complete. Create wording templates for more exact phrasing like, “I will have that complete by stand-up tomorrow morning.” Help your team provide the data that is necessary, not merely informational.
Given the heavily collaborative nature of software development, failures in communication are most often the cause of derailment of a project. It is faster and more cost effective to ask twice and code once rather than let failures in communication result in code rework.