This is the fourth article in a series of blogs discussing individually each of the 12 Keys For Successful Enterprise Projects, published in my blog on Tuesday, June 26, 2012.
Today, for most organizations, the development lifecycle is a black hole. Requirements are developed in a list, usually captured in either Word or Excel. From that point forward until a new system is implemented, requirement stakeholders are often left in the dark.
Usually, stakeholders are not even provided a copy of the business case, the project vision, or the project objectives as part of a validation process. How can they provide meaningful input without this information? After the requirements phase is completed, the information void gets worse. Except for possibly being able to view the project plan and maybe receiving occasional status reports often presented only to the project owner, stakeholders frequently have no idea about project status at any point in time.
This results in stakeholders asking themselves “Are we 50% complete? 75%?” There is really no way to gauge real status if the project team goes off to the corner to do their work and the client is left out of the development loop. Clearly, real transparency is key. So, the first benefit to project transparency is being able to accurately understand where you are in the development cycle.
But transparency brings other more striking benefits. If you can see what tasks the team is working on, review the latest internal project plan, download the source code, read the latest technical documents, etc., participate in testing, and the like, don’t you think the team is more likely to be on their toes? If the development team knows the client is watching, they will naturally try extra hard to get things right the first time and thereby avoid costly refactoring. Transparency improves productivity and accountability.
With transparency, all parties involved on the project will achieve a better result if they work together and cooperate as partners. Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers – a partnership. Too often, the relationship between development team and customers becomes adversarial. Managers who override user-supplied requirements to suit their own agenda can also generate friction. No one benefits in these situations.
A collaborative effort can work only when all parties involved know what is needed to be successful, and when they understand and respect what their collaborators need to be successful. As project pressures rise, it’s easy to forget that all stakeholders share a common objective: to build a successful software product that provides promised business value and rewards to all stakeholders.
The fact is that people are much better at describing what they think they want and then able to describe what they like and don’t like when an option is presented to them. In other words, it is best to work with stakeholders to identify what they think they want, produce something that reflects that understanding, get feedback from the stakeholders, and then update the solution to reflect our improved understanding. The implication is developers need to work in a more evolutionary and collaborative manner with stakeholders to develop solutions that reflect the stakeholders actual needs. To accomplish this, developers must work closely and regularly with stakeholders. This is the goal of agile; however, stakeholder and developer collaboration continues to be one of the greatest challenges for development projects.
Often, stakeholders are interviewed or participate in a focus group at the front end of an initiative, after which they have no other contact with the project until the software is ready to be deployed. My experience in delivering successful applications is that stakeholders should be involved through the entire project lifecycle. They should participate in activities such as:
- Reviewing design documents
- Participating in software and prototype demonstrations
- Joining in retrospectives and capturing lessons learned
- Providing additional information for unclear requirements
- Building test scenarios and test cases for user acceptance testing
- Performing user acceptance tests
- Approving changes to requirement specifications
- Defining transition requirements
- Preparing the organization for change
Enfocus Requirements SuiteTM provides powerful collaborative tools and methods to facilitate and perform these activities in a completely transparent environment and in a manner that complements (not replaces) project management and software development applications.
[cta id=”7662″]