Doing BPM... On Yourself   

By Jennifer Laws, Associate Technical Writer, IIBA   
Business process management is a management approach concerned with ensuring that change initiatives undertaken by the organization support the business needs and stakeholder interests. When an organization starts on a project, the appropriate people must be in place to make sure the needs of the organization are being met effectively and efficiently. Who these people are depends on what the project is. Recently I had the pleasure of speaking to two such individuals: Deb Oliver, who works as a Business Analyst, and Sandra Bauer Heinz, who works as a Quality Assurance Analyst. They’ve worked together recently within International Institute of Business Analysis (IIBA), and were happy to provide some insight into how they approach projects, outline processes, and ensure optimal results.
One of the first steps in approaching a project is to understand the business need and the impact the change initiative has on the organization. A high-level requirements document is produced that identifies the project’s purpose, the stakeholders, and what requirements are parts of the change initiative. The scope must be defined and understood, to detail what is in scope, and what is not. And, of course, the critical success factors are outlined, so the success of the project can be measured.
It’s also a good idea to try predicting any possible issues, so the number of bugs can be reduced early. This is where a QA person becomes important—in the early stages of the project, to make sure that documentation is clear and unambiguous. “Far too often people translate QA to ‘testing’,” says Sandra, “and they’ll get me involved when they have a finished product. That’s far too late.” The later on that issues are discovered, the more it costs an organization, so it’s a big benefit to be thinking of quality right from the start.
All stakeholders must review and approve the high-level requirements document before the organization moves forward with the initiative. This document will set the course for the project.
In project teams consisting of people in various roles, it must be determined how they will work together to make the project a success. When the team first comes together, setting clear expectations for each person—responsibilities, deadlines, etc.—will keep the project efficient and on task.
Of course, working is also a learning experience. I asked for some lessons learned when Deb and Sandra worked together, and their responses reflect some key things to keep in mind when approaching any project.
Do not underestimate the complexity of the project!
Defining detailed requirements as early as possible will help you identify solutions that will work for you and your business. Sometimes requirements seem straightforward, but the solutions can be incredibly complex; it is important, therefore, to have detailed design specifications in advance, in order to drive out technical complexity.
It’s especially important that all the members of your team understand the purpose of the project and the end goals, as well as the business needs—especially for someone like Sandra, who is in charge of eliminating mistakes and making sure everything works. She says: “In order to really do QA well, QA has to understand the business needs. If you don’t have that link to your business, QA would struggle. I think that’s something worth highlighting in the process overall.”
Work with designers and developers to receive detailed and specific technical design specifications.
Technical design specifications need to be detailed and comprehensive.  “Sometimes,” says Deb, “we fail to remember that developers and third-party vendors are human, and they may not know our systems the way we know our systems […] and it really is our job to make sure we fill in the gaps.” Technical design specifications should be compiled early and in detail to avoid having to re-engineer later.
BAs can facilitate this by ensuring that the requirements clearly define both what is already in place and what is needed in the future. This way, surprise discrepancies can be avoided, and the need for stakeholder negotiation can be minimized. Where discrepancies arise, stakeholder negotiation is required to determine how much change is acceptable. How to determine this? Deb says it best: “It really all comes down to what the business deems to be important, given the time allocated for the project.”
In any project, it is key to have people making sure that workflow is efficient and effective, ensuring business needs are met, reducing miscommunication, and enabling all stakeholders to understand their requirements and roles. These are all parts of business process management, and are incredibly important to how an organization operates every day.
Thanks again to Deb and Sandra for your insights and for taking time out of your busy schedules to speak with me!