Much has been written over the past years regarding the monetary wastage of failed projects around the world. Billions of dollars lost to a staggering 40% of IT Project failures. Why does this happen one may ask when seemingly there are so many ‘experts’ and knowledgeable people in IT and software development? - still projects fail.
When we look back and analyze the projects, we see a clear pattern of common reasons for the failures.
Unfortunately, in today’s economic climate when organizations should become more frugal and careful as to where they spend their money, it appears evident we will continue to see an increase in failed projects until the collective voices from organizations such as the International Institute of Business Analysis®, Zachman Group and The Open Group Architecture Forum are taken seriously and organizations begin to support the practice of good business analysis.
Based on our experience in business analysis and EA, we’re sharing the 10 key steps that should be in place to ensure the successful initiation of a Business Project.
Be clear on the Strategic Objectives the project must achieve
All businesses have a strategy – some simple, others complex – it depends on the nature and size of the business. However, a strategy may end up as nothing more than words on paper unless there are definite action plans put in place to achieve the strategic objectives. The larger and more complex an organization, the more difficult it becomes to do. How do we know the strategic objectives documented during a strategic planning session have taken into account the actual problems or opportunities that could prevent (or enable) the organization from achieving its strategy? Who gives guidance and counsel to the strategic planners and what is their counsel based on? The practice of business analysis is unlike any other. Business Analysis practitioners need to see the organization through different eyes and ask questions such as:
- “Why does this organization exist?”
- What components make up this organization? (People, technology, channels, products, services)
- What are the products and services the organization provides?
- Who are the organization’s customers and suppliers?
- What is the geographical spread of the organization?
- What information does the organization need to keep in order to manage the business and to adhere to financial, legal, health and safety and government requirements?
- What information does management need to make informed decisions in order to operate the business successfully on a daily basis?
- Who are the local and international competitors?
Only when there is a common view of HOW the above elements come together in unison is it possible to identify GAPS that prevent the business from operating like a well-oiled machine. These ‘gaps’ should be investigated by Business Architects or Strategic Enterprise Analysts, who look across organization boundaries to ensure that a consistent solution is put in place that will solve the actual business need (root cause) and will be aligned to the strategic goals of the organization.
In organizations that have a mature EA (based on renowned Frameworks (i.e. TOGAF, Zachmann, eTOM), the Business Architecture effort will provide a clear project roadmap and prioritization to guide the correct allocation of funding, resource allocation and solution approach to the right projects.
How does the Organization currently operate?
In order to fix something, we need to understand how it currently works. Where is the actual problem? When does it occur? How does it occur? Who is impacted? How many times does it occur? To answer these questions, a Business Analyst uses techniques such as job-shadowing, observations, diagnostic analysis, root cause analysis and creates diagrams to gather the information, validate the information and gain consensus through collaboration across stakeholder roles. Model! Model! Model!
Models help us to:
- Visualize reality and to understand how work flows across organizational boundaries (roles and structure)
- Focus stakeholders, ask the right questions and to gain consensus across groups
- Gather information that is usually stored and kept all over the place
- Elaborate important points in textual descriptions to improve organizational understanding, terminology and provide the measurements and metrics that determine the cost to the organization
To get effective usage from models requires the use of a tool that actually supports the practice of business analysis. In my career I have used many tools and mostly found them to be too structured, too cumbersome and without the ability to create relationships between the different artifacts.
Analysts must deliver. More often than not, the effort to use the tool distracts from the effort to investigate and represent the business correctly.
Justify the Project
There are primarily two categories of projects – Discretionary and Non-Discretionary:
a. Discretionary projects are motivated by the financial or un-quantifiable benefit (ROI) that the organization will receive by investing in the project.
b. Non-Discretionary projects are motivated by legislation; health & safety; audit; compliance; government rules; and so on. In other words, these projects take priority over Discretionary projects and are obligatory. It is therefore not necessary to provide a financial justification for them – they have to happen. Organizations typically allocate a certain portion of their project budget to Non-Discretionary projects; however it is important to justify and obtain consensus on the solution approach that will be implemented and to be aware of the risk/s to the organization if not implemented.
Every Discretionary project should have a financial justification to support it. All projects cost money, no matter how big or small, thus Business Architects/Strategic Enterprise Analysts work with the organization executives to provide factual information of how much the project will cost (expenses), how much money the organization can expect to receive in growth income, savings and/or improved customer value (return on investment) and by when (how long will it take to break-even and when growth income can be expected).
There are many ways in which a business problem can be solved or an opportunity exploited. For example, based on size and risk factors, a solution option may be to develop in-house; purchase off-the-shelf; out-source or re-engineer existing processes. To ensure the right decisions are made by the Executive Team, each option is investigated and measured against the business needs, a financial feasibility study is conducted and a cost vs benefit analysis is produced, which will provide a financial justification of the correct solution approach to take. At this point the Executive Team will make an informed decision as to whether the project is a ‘Go’ or ‘No Go’, based on the expected financial or un-quantifiable strategic benefits the organization will achieve. The Business Decision Pack (Business Case) is a living document and must be revisited throughout the project lifecycle to ensure that the cost of the project will never out-weigh the end financial benefits that the organization expects to receive.
Initiate the Project
The success of any project is directly related to people. Very seldom is the failure of a project related to technology or to a SDLC methodology. Allocate the right people with the right skills level and a ‘can-do’ attitude to the project. Project Leaders must have a clear vision of the size and risk level of the project to recruit the right people. For a high priority or high risk project, it may be necessary to recruit highly skilled people who can demonstrate successful previous work experiences (yes, they may be more expensive but the organization could recoup an earlier return by implementing the solution successfully). For a small-medium sized/low–medium risk project, Project Leaders may be comfortable with recruiting Novice or Intermediate level skills, knowing that a learning curve may impact the proposed timelines unless they are mentored and coached throughout the project, but their rate may reduce the project expenses. These types of considerations and risks must be factored into the decision package that is used to justify the project.
When human resources are allocated to the project team, it is crucial that everyone is aware of their role and responsibilities. The roles and responsibilities should be clearly defined and agreed upon to maximize delivery and minimize conflict between team members. All team members are to have a clear understanding of the project purpose, the priority of the project, whether their project is part of a program and whether the program is part of a portfolio of projects that has been authorized by the Organization’s Executive as being necessary to achieve the Organization’s Strategic Goals.
Project Team members must be given access to the Business Case, models and pre-project work that was done during the analysis of the enterprise. This eliminates rework and provides a baseline from which to begin decomposition of the Business Requirements (as stated in the Business Case) into Solution Requirements, tracing back to the Organization’s Needs.
Determine Project Boundaries
There are 3 types of boundaries that project team members need to be aware of:
- Organization boundaries – that means scoping the organization business units and roles that fall into the target area of investigation. This is a very important exercise especially for complex, global organizations. Business Analysts need to have this understanding as it will be required for planning their Requirements Activities. Who are the stakeholders? Where are they located? Are there language differences? Are there cultural differences that need to be factored into the planning estimates?
- Project Boundaries – what do we have to do as a team? What skills and expertise do team members have and how can their skills be exploited to the advantage of the project?
- Solution Boundaries – what functions/features does the solution need to have to achieve the business need?
Agree on Standards
The most consistent comment I hear in many organizations and from many business analysis practitioners is the lack of agreed standards and templates. I want to address three sets of standards that are important to project success, they are:
- Business Analysis Standards: The practice of business analysis has been a critical role on projects for as long as I can remember (I have been a BA practitioner for more than 30 years). The model types documented above were used then as they should be used now. However, with globalization and the increased complexity of organizations over the years, there has been a separation of responsibilities for business analysis into different roles, i.e. Process Analyst, Data Analyst, Business System Analyst, Solution Architect, Business Architect, Data Architect, Requirements Analyst and so on. We have also seen the emergence of roles and titles supporting different practices, trends and methodologies such as Scrum Master, Lean, Six Sigma Black Belts and so on, all of which add to the complexity of competencies needed to land successful projects. The International Institute of Business Analysis® was registered as a non-profit professional association serving the growing field of business analysis to the international business community. Their mission is to develop and maintain standards for the practice of business analysis and for the certification of its practitioners. The Business Analysis Body of Knowledge® defines the skills, techniques, tasks and deliverables required of Business Analysis practitioners. The growth of the IIBA® across the globe has been phenomenal as organizations grapple with an increase in failed projects and an inconsistent understanding of Business Analysis.
- Modeling Notation Standards: The models used by Business Analysis practitioners and those documented in the Business Analysis Body of Knowledge® originally came from two software development methodologies, primarily Information Engineering (Process Modeling and Data Modeling notations) and Object Orientation (UML modeling notations). From a Business Analysis perspective, the models from IE and OO are complementary and can be used to communicate requirements or organization knowledge from different perspectives, however there must be consistency and accuracy in the usage of the models. In recent years, greater emphasis has been given to modeling notations such as BPMN and ArchiMate primarily to improve and standardize modeling and communication skills. The implementation of standards consistently across organization roles can only become effective with the implementation of a modeling environment that supports a true repository of template and modeling objects.
- Documentation Template Standards: Inconsistent usage of document templates has been an ongoing dilemma in most organizations. Not only in textual type documents but also in modeling environments and matrix type documentation. The implementation of documentation standards consistently across an organization can only be effective with the implementation of a tool that enables the customization of a document template but also primarily supports the creation of relationships to bookmarked content, thereby linking the visualization of a model to textual descriptions in Word or Excel documents.
Identify the Stakeholders
On every project, there are two stakeholder groups that have to be considered, they are Direct and Indirect stakeholders. Direct Stakeholders are those people or groups who are directly impacted by the project solution. Typically they are Line of Business Managers, End Users, Supervisors, Customers, Suppliers, etc.
Indirect Stakeholders are those people or groups of people who are not directly impacted by the project solution but who will provide input to or expect to receive output from the solution. Typically, these groups are Marketing Departments, Finance Departments, Audit, Compliance, HR, Operations, Regulatory Groups, etc.
In a project environment, the initial starting point to identify Stakeholders is the Business Case, however Business Analysts will identify key stakeholders from the models they build whilst interacting with the Organization’s business and IT groups. In all cases, it is important for Business Analysts to build relationships with stakeholders and to create stakeholder catalogues/matrices, to trace Requirements to stakeholder groups and to ensure all Stakeholders’ needs have been satisfactorily addressed. Organization Stakeholder catalogues are needed to understand the key competencies an organization should have in order to conduct its business. Identify stakeholders as early as possible during the planning phase of the project to get stakeholder buy-in and attendance to Requirements Elicitation Workshops and to reduce the risk to the project by the stakeholders who do not attend Business Analysis sessions when required.
Elicit Requirements
The art and science of working with stakeholders to uncover requirements is underestimated by most organizations. In many cases, the role of the Business Analyst has been down-graded to note taker at a meeting and documenting what invitees want. It is no wonder projects fail due to poor requirements! Business Analysis practitioners must be mature individuals with the ability to work amongst groups of people, using their knowledge of the organization’s policies, operations, systems, business units, products and services to discover the real need of the business and to design the requirements based on the solution approach agreed upon within the Business Case. Business Analysts must be Managers, Communicators, Leaders, Consensus builders and be able to work across the organization’s hierarchy without fear or intimidation. Therefore they need to be highly respected and trustworthy to win stakeholders over and to facilitate effective Requirements elicitation workshops.
Facilitating a requirements workshop is unlike facilitating any other type of focus group session. The Business Analyst must be very well prepared (and must have prepared the stakeholders prior to the workshop) and use diagrams to focus and control the workshop/s which could in some instances, become quite heated when stakeholders do not see eye-to-eye. There is nothing worse than being in a workshop where the Facilitator uses the incorrect diagrams or is unable to use diagrams effectively to hold the attention of the audience. Modeling is a key skill all business analysis practitioners must master, whether they are modeling at architecture conceptual level, logical level or physical level. There are simple principles for every model type and business analysis practitioners should not only be able to create models, but must be able to correctly read models that have been created by other practitioners.
The importance of planning at the beginning of the project cannot be over-emphasized and is needed for stakeholders to understand their commitment to the project and to be able to schedule their diaries accordingly to meet the project timelines. Collaborating with stakeholders is ongoing throughout the project and is made more difficult for Business Analysts if the boundaries of the impacted organization areas stretch beyond local and international geographical boundaries. Virtual meetings, webinars and interactive collaboration tools are available and should be considered by project teams.
Build Requirements Packs
Requirements will never be completely discovered during one workshop with stakeholders. It will take several iterations for requirements to be discovered, analyzed, documented and validated before approval can be obtained from stakeholders. What requirements to work on first should be addressed during a Requirements Prioritization meeting with the key stakeholders? Allocate Business Analysts to work on the requirements that will bring the organization the most for its money by prioritizing based on ‘High Importance’; ‘Medium Importance’ and ‘Nice to have’. Prioritization is important for a number of reasons:
a. It keeps project team members and stakeholders focused on the right work
b. It allows the Project Manager to manage dependencies and allocate resource
c. It enables Business Analysts to build requirement packs that contain all of the elements necessary to produce a complete requirement. For example, Use Case Diagram, Use Case Narrative, Activity Diagram, Screenshots, Class Model, Business Rules, Navigation Rules, outputs such as Reports, letters, statements, etc., User/Permission matrix, User Stories and so on. When business approval is obtained, the pack is base-lined for the development team to enhance requirements by adding technical elements needed for development to begin.
To support this kind of team collaboration, it is necessary to have a shared repository where folders are set up to contain all the above elements for each requirement.
Assess the solution
When initiating a business project primary attention is given to ensure the right solution is selected to solve the business problem or exploit the business opportunity. Throughout the project and more specifically during development, the focus of the project team is to ensure the ‘solution is built right’. This means requirements must be traceable to the original business objective and through the SDLC to Test cases. Traceability is bi-directional, which means that any change made to the requirements during testing must be traceable to the business need.
Conclusion
The economic climate in today’s world will continue to force businesses to become leaner and meaner and to eliminate irresponsible project wastage. This, in most people’s language, means that organizations need to truly support the practice of business analysis, from the point of setting up the correct architecture views that describe the business, to identifying the right projects to meet organizational strategies, to prioritizing and funding projects correctly and to ensure the right people with the right skills are allocated work in dedicated teams that deliver each project successfully. Supporting the practice of business analysis includes the provision of a tool that supports:
a. An intelligent modeling environment
b. The reuse of objects and relationships between objects
c. The ability for textual content to be linked to objects
d. Collaboration across team members, stakeholders and organizational/regional boundaries
e. Enforcement of good practice standards
f. Easy retrieval and creation of different views
g. Ease of use and the facilitation of creative thinking
h. Requirements packaging – retaining elements to create a complete requirements set
Download the full version of this White Paper for free at: https://www.orbussoftware.com/resources/downloads/10-key-steps-to-initiating-a-business-process-project
Question