Laura’s note: Have you ever wondered exactly how a project or IT manager views your activities as a business analyst and why they ask you the questions they do? David Wright recently published Cascade, a book about delivery successful IT projects, especially in a multi-project environment. After spending 25 years in various IT roles and “having seen it all”, David aims to deliver a concise guide for project success.
Today he’s sharing an excerpt from the book about how, when, and why to engage a business analyst in an IT project.
Your Business Analysts are the face of your project to the widest number of business people. It is their job to gather and consolidate all the needs and desires of the business — the Requirements – within the project scope, in such a way that the business people can understand and approve the result (“Yes, that is what I will pay for.”), and that designers/developers can build the system that will meet those needs (“Yes, I can build something that will do this.”).
If your project has relatively few types of business people who will use the system, and you are creating new software, especially when it is to support new functions such that the business does not yet know all of its needs, then by all means, gather the users, business analyst, developers and testers in a room and pound out the system in an agile, iterative approach. If the IT participants can perform multiple roles, then the ratio stated above does not matter.
However, I am betting that 75% to 90% of the time, your project will not look like this. Even if the user scope is narrow, it is still a common tug-of-war with business management to get users involved to the extent needed for agile approaches; or the knowledgeable users you need cannot be spared, and substitutes are provided who cannot give the team what it needs without checking with management or those people you really wanted.
The other reason is that many projects have a wide number of potential users, with different (and maybe what looks like conflicting) needs, possibly spread out over multiple locations, perhaps literally spread around the world. So, someone has to deal with these complexities, and consolidate the results so that the appropriate solution can be delivered.
These days, that person is what is now commonly called the Business Analyst, charged with documenting the Requirements for the project. How Business Analyst’s do that, and what the Requirement deliverable looks like and contains, is a topic for many books, and there are many, from Yourdon to Wiegers, so I will not write one today. This should be a crucial part of the methodology you use in your shop, whatever the specific techniques or approaches it contains.
In essence, a methodology is used to make delivery of a solution faster, less work, and with a quality result. One of the ways it does this is by fostering communication between participants by providing a common language and structure. This is crucial for the business analyst’s job, as their role is essentially communicative; their deliverables are intermediate, used to assist in creating the final delivered system. So, an important test of your methodology’s effectiveness is if your developers can take the Requirements and build what they say is needed, without the developers having to spend more time trying to get any more detailed information that the Requirements did not contain.
When this is the case, my experience has shown that Business Analysts working with business people can, after completing an initial part of the Requirements, provide enough content to the rest of the team to keep two developers occupied with design and coding efforts, which is where the most time on your project will be spent. Separate testing of the new code produced by two developers will normally require one tester; many companies actually combine the Business Analyst and Tester roles.
|
By David Wright. David Wright is an IT Professional with over 25 years experience, mainly in the Business Analysis and Architecture fields. That makes for over 25 years experience on IT projects, delivering information systems in insurance, investments, IT administration, express delivery, large equipment leasing, human resources, and many more. View more blog posts by David Wright |
Related posts:
Loading ...
