Let’s assume you’ve done your homework and scoped a project that drives business value. It’s easy to take a deep breath, kick back, and relax…waiting for the implementation of these great ideas to see themselves through to completion. But your work as a “bridger” is only half-way done. The task at hand is to engage the technology team in actually solving the problem. Without a focused and engaged IT team you’ve got a well-defined problem that will never be solved.
I hold a firm belief that everyone deserves the opportunity to understand the larger context of the work they are doing. This doesn’t mean that everyone will get it or even care, but the opportunity should be there. It simply does not make sense to close off information about the value a project provides to an organization or the real problem you are trying to solve. In even the smallest of projects, you will probably engage multiple people at different stages of the project…think about it…development leads, quality assurance, developers, database administrators, infrastructure folks. While a project kick-off meeting is valuable and important, it won’t get the whole job done. Providing business context should become part of your DNA when talking with an implementer.
I am passionate about this today, because I stumbled over myself on this one last week. A new member was added to the team to complete a relatively discrete data task. I had nearly perfectly detailed requirements about what needed to be done and we talked through them. I completely forgot to step it up a level and communicate why we were doing this and what I knew about the data and users. As a result, the new team member spent a few hours wrestling with what he rightfully assumed was a real issue which, once we talked through it, had a simple solution. So, don’t get task oriented and forget to share your knowledge. Before walking through detailed requirements, take a moment to consider the perspective of the other person. Are they new to the project? Are they already engaged in a piece of the project to which this can be related? What would you want to know if you were in their shoes?
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 3 comments… read them below or add one }
A very important post Laura. I would go one step further however and rather than just suggesting that “everyone deserves the opportunity to understand the larger context” I would assert that without that larger context the quality and value of the outcome will jeapordised and probably diminished.
Related to this is the commitment and ‘buy-in’ you get from people is greatly increased by the increased level of information and communication. Simply ‘telling’ someone what they have to do is the bottom rung on the scale, and ensures a transactional approach aswell as a lack of buyin. At the very least, being able to ’sell’ the requirement (Here’s why you need to do …) provides some ability for people to get on board. Any opportuntiy to progress beyond that and get collaboration from people to help formulate the way forward, or ideally be able to ‘co-create’ will produce vastly better results.
Hi Derek,
Excellent point. Making the transition from sharing to collaboration on how to solve the business problem is key.
Laura
Similar to how programmers sometimes make prototypes, the User’s Guides written by the Business Analyst would have mock-ups of what the screens would look like. The programmers usually had these within 2 days of the Feature Blitzes and the designs would change by the two-way communication they engendered. That is, the programmer would suggest a better way for some sub-feature or button and the BA would change the design. Likewise, the programmer would actually program what the BA had hoped for as the pictures left less room for misinterpretation. The programmer would then give actual screenshots to the BA or the BA would get them his/herself from a code drop to replace the mock-ups with actual screenshots in the User’s Guide.