Requirement management is a good starting point and one of the significant steps in managing IT initiatives effectively to achieve its business value.
IT is business, every IT initiative needs to have a well-defined business requirement and well-supported business sponsors. What are the most effective vehicles for understanding business requirements? What are effective ways to ensure that non-IT stakeholders are engaged and performing their appropriate roles? Talking to business partners is clearly essential, but are informal discussions sufficient? How does IT get the right executive sponsorship and commitment, who should they be, and perhaps more important, what are the roles that they must play?
Elicitation, Analysis, Documentation, Reiteration, and Buy-In: The customers, users and all stakeholders including suppliers, partners, and all internal functions hold a stake in the requirements. Also, assume any inputs are incomplete from a holistic perspective and are filtered from the silo's functional view, the reiteration of the requirements development process is essential to arriving at the "real" requirements. Talk to the people who are using or will be using the proposed solution. Talk as much to the people that will benefit from the new requirement as those who will feel pain from not meeting the new requirement. Sometimes it is the same person. Sometimes it is not. Sometimes it is easier to talk to one than the other, but both are required to get the carrot and stick view of requirements.
IT initiatives are business projects and, therefore, require participation by the entire business: For this reason, the sponsorship and commitment must begin at the top of the hierarchical authority chain (C-Level), and flow downwards across the entire business as IT may be responsible but does not have authority outside IT. Since the effort is cross-functional, cross-functional participation and cooperation are critical. Management of the effort is only effective within a function. For this reason, they all must play a leadership role and be committed to doing the right thing for the business, not the wrong thing to protect their best interests. If the person at the top wants the initiative to happen and be successful, that will promote the executive staff to be receptive, but it is only the potential value they see in the initiative that will "seal the deal." Until they see value in what IT is doing, the sponsorship will only be "showing face" and there will be no commitment.
To demonstrate the value, collect data and information: As requirements are gathered and managed and discussed with executives and teams, focus on those requirements whose improvement has the most benefit to the business, and keep the stakeholders focused on those requirements and relationships, while the requirements manager never loses sight of all requirements and relationships. Facilitating requirements negotiations is very beneficial to keeping everyone involved. If a decision negatively affects a stakeholder, make sure the stakeholder understands why the decision is the best in the "bigger picture." Depending on the domain and its culture, sometimes a use case model is good for requirements capture, sometimes a formal requirements document. Attempt to get prototyping and/or pilots on the agenda so the client can see tangible results ASAP, and not just models and documentation. Try really hard to get access to the participants at the coal face, where you can learn what really gets done, and current shortcomings.
IT initiatives are unlike others as they are always enterprise-wide, and IT oversees business processes: When it comes to collecting the business requirements, IT needs to take the traceability path of where the requirements come from, and IT requirements need to be functionally structured to serve each functionality the enterprise needs, and it often requires multiple organizations to produce the overall functionality/capability required. To see where all the functional boundaries are and who is organizationally associated with each requires an architect with a holistic perspective and ability. There’s the difference between business requirements and IT requirements. IT requirements are allocated to IT from the business requirements. Business requirements drive everything the entire businesses do, way beyond IT, but many of which IT is "allocated" its share of. So IT has to oversee the full set of the requirements to ensure the cohesiveness and to determine all the customers, users, and stakeholders and obtain their involvement. Leadership has the responsibility to enable the team and assure it has the capability to sustain the involvement. A formal business requirements initiative led by a capable architect performing (1) enterprise mission and stakeholder needs analysis, and (2) enterprise system requirements development and management, with the initiative backed up by executive sponsorship and commitment and advocated by leadership.
People are the key success factor: The two important participants for IT initiatives are the executive sponsor: the person at the top who has to promote the initiative, and they are skilled at defining the business requirements in a business language describing targets, customer needs, and personas, competitor offers, current product SWOT and all identified opportunities. Also, the person doing the work has to show the continuing value. They are the key to the success readiness checklist. Without both, you cannot get over the "responsibility without authority" barrier. The challenge is really about helping the sponsors, being able to ask the right questions and fitting together different strategy components. However, in reality, more IT organizations have invested in training and tools to help execute on the project, but many product management organizations have not made similar investments. Agile and other methodologies are pulling the sponsors and product owners in the right direction, it is possible to create a product management framework where product plans can effectively communicate the strategy/opportunities/problems to the developers. It’s important to note this may or may not include any reference to technology or solution approaches, but in practice, it helps for the sponsors to understand the key product development considerations (skills, resources, IT roadmaps, etc). If this is done well by the sponsors, then a walkthrough of the business requirements and identified opportunities can be done as part of a "JAD" (joint assessment & design) review meeting to allow IT to begin shaping system/IT requirements. Here's where IT can help the sponsors talk to gaps, assumptions, risks, etc; to help shape the prioritization of the opportunities, level set scope, and approach. This includes alignment of product roadmaps to IT roadmaps to business roadmaps.The requirement management is a good starting point and one of the significant steps in managing IT initiatives effectively, it directly impacts on how successful such initiatives can not only be delivered on time or on a budget, but, more importantly, ON-VALUE, and reach customers’ expectations.
0 comments:
Post a Comment