Sunday, April 7, 2013
Deliverables vs. Delivering
I remember years ago during football season watching a commercial produced by IBM. This guy was on a beach with a bunch of washed up monitors and I think some other pieces of equipment. I recall his basic message was that you could produce the greatest technology in the world – but if it doesn't add business value - then it’s basically “junk.”
It’s interesting how sometimes on our projects we become rigidly associated with certain SDLC deliverables. From a project management standpoint, this isn’t necessarily a bad thing, since it helps provide a clear means of tracking progress. But if we’re not careful, what can happen is that we become so focused on our deliverables that sometimes we lose sight of who really has the most at stake here. And that’s the user.
I’m not saying that deliverables aren’t important. As BAs, we certainly should have a level of
accountability for the work we are responsible for. It’s just that in the end these splendid artifacts we work so hard to perfect become fairly useless if the solution doesn’t meet the needs of the business.
It’s my belief that a true test of a success is the user base getting the business value they expected from the solution in the first place. Keeping the business engaged (with the right level of communication) consistently throughout the project can help increase our chances of achieving this outcome. Also, using good elicitation techniques to get the right requirements from the start is essential. However, if users seem confused or disconnected during acceptance testing, then that’s red flag. Therefore, it’s important that we use acceptance testing as an opportunity to elicit feedback on how we can help smooth the transition to go-live.
For instance, simple things like having a good user guide in place - which walks the user through everything from getting access to instructions on how they can get the most from the system to do their work - can go a long way towards ensuring true success. Therefore, incorporating user feedback throughout the process not only ensures that our own deliverables are correct, but the users will feel more engaged. This will significantly help our chances of delivering a successful outcome.
Lesson learned: Focus on the user first, and keep them actively involved throughout the
implementation of the solution. This not only increases our chance of implementing a solution that works, but it helps us avoid the great misfortune of delivering “junk.”
Subscribe to:
Post Comments (Atom)
I like this article. I would be more interested to know how to do the process. Reading many articles gave me an idea what the process is. But the main question always remains is "how". I believe - If "What, how and why" are answered and evaluated, the project is sure to succeed.
ReplyDeletePlease keep posting.
Thanks!
Lakshmi Venkat
Thanks Lakshmi. Unfortunately, I really don't have a "silver bullet" with regards to determining the most optimal BA approach to use, because I think that decision would depend on many factors (such as the business need, size and complexity of the stakeholder group, project type and complexity, organizational culture, and any applicable regulatory requirements - just to name a few). In short, there are many different approaches and techniques you could use - and any one of them may appropriate in a given situation.
DeleteFor capturing the solution scope and user requirements, I'm personally a big fan of context diagrams or DFDs combined with User Stories. The concept of a User Story in of itself may seem simple, but the trick is ensuring that you have a cohesive and complete set for your planned release. This can go a long way for ensuring that your user requirements are properly communicated - especially when working with external vendors. The other thing I like about User Stories is that they can then be further decomposed into Use Cases (if that's an approach you choose to take).
One particular technique that I've found really helpful on my current project is the concept of "Use Case/Storyboarding". I used a tool called PowerStory,
which was developed by Martin Crisp. (You can also take a look at the post below that Martin started and I commented on). I've found that combining steps with visuals can be a powerful approach for eliciting the right requirements. Additionally, what I learned was that you can be successful with a "hybrid" approach (meaning, using agile techniques in order elicit the requirements you need for your SDLC documentation). Perhaps a topic for a future "lessons learned" post :-)
Nice Article Glen. To answer Lakshmi's comments, the process on a top level would be to ask "why" till you drill down to the actual requirements.From there on the process will depend on whether you follow waterfall model or the agile model.
ReplyDeleteHopefully my 2 cents makes sense
Thanks Balaji. I completely agree that using a Q&A process as you've mentioned can be an excellent way to help us understand the nature of the problem we are trying to solve. I've also found that using simple things such as post-it notes and whiteboarding can be a great way to help us understand stakeholder needs and elicit our initial requirements. Additionally, I've learned that using a hybrid method (which I mentioned in my above reply to Lakshmi) that combines the aspects of both plan and change driven approaches can be quite effective as well.
DeleteThis comment has been removed by the author.
ReplyDelete