Real Business Analysts Don’t Play Ping Pong at Work
I recently saw an Argentina-based ad about a non-millennial who was hired to work in a creative company with lots of ping pong and alternative work arrangements going on and he was having trouble fitting in – and oddly an adorable pug dog kept showing up in the ad and staring at him.
He even missed the alert for work from home day and showed up to an empty office building. He was frustrated to say the least.
While things like sharing the elevator with bicycle riders carrying tires and bikes in the office place is normal as is many part time to full time work from home scenarios, I can empathize on other aspects of the creative workplace. They can be conducive to work but it can be a huge distraction as well.
Water cooler discussion is so overrated it isn’t even funny. I’m so much more productive working from home as I am organized and efficient enough to make it work. It probably isn’t for everyone, but when you have that nice office at the typical workplace you find yourself losing productivity to your employees and friendly co-workers who like to come and discuss their weekend activities for a couple of hours everyday. I have 10 more hours every week of productivity just because I’m working from home… and that doesn’t even address the time saved not driving to an office somewhere.
So let’s move beyond the ping pong and the open environment and the work from anywhere discussion and get to the real point – what are productive and effective business analysts focusing on? On the tech projects I have been part of, the business analyst is usually more focused on these five key project responsibilities…
Defining business processes.
Before anything else can be done, the business analyst must understand the business processes of the client organization and why the project is needed. That may include the client organization getting a handle on their own business processes. Please note that this is before project requirements are really determined, even if the customer thinks they know what those project requirements are. Whatever they have in project requirements, set those aside because everyone must first understand the “as is” state of the business processes and gain understanding of the “to be” plans for those affected business processes. This is the beginning of the high level project requirements. Or at least the beginning of the building stage of those project requirements.
Documenting project requirements.
The business analyst is involved in just about everything about the project post-kickoff and maybe even pre-kickoff if they are fortunate enough to get assigned that early (and if the project manager is fortunate enough to get their help, insight, and skill set that early) in the engagement. It is possible that none of this involvement is more important than the act of planning, extracting, sorting through, defining and documenting the complex and detailed project requirements for the project engagement. I’ve always said that good, complete project requirements are the lifeblood of the project. Without good, complete, detailed project requirements, you’ll likely miss the mark on developing what the customer and their end users really want and need. You’ll experience many change orders, re-work, missed deadlines, off the mark project deliverables and… in the end… have a troubled and frustrated project client who isn’t likely successfully using the solution as planned and isn’t likely to immediately run around giving you and your organization high praise and reference-able recommendations.
Moving user acceptance testing (UAT) along productively and successfully.
Another important area of coverage for the business analyst is the laborious, but critical process of user acceptance testing. The UAT is where the customer runs the basically finished technical solution through it’s paces and confirms that it does what they need it to do. What are they testing against? You guessed it… the project requirements. So going back to those… you can see at least one key reason those well documented project requirements are necessary. Another key input into the user acceptance testing process is the test cases and testing scenarios. Most clients aren’t very experienced in putting those together and actually performing the testing. The BA can’t really do all of this for them… that would be a conflict of interest because in order to get non-tainted sign off of the user acceptance testing it needs to be the customer performing all of these activities. But the business analyst certainly can and often does help – significantly help – guide the project client through this process successfully. The UAT does have a defined place and time on the project schedule – often one to two weeks – so it needs to end (successfully!) and then move on. The BA helps keep it on track toward successful sign off.
Ensuring the project is closed out successfully.
At the end of the road is the project closeout and final sign off and acceptance. The business analyst is always going to play a key role in this – working right along side the project manager to ensure all the i’s are dotted and the t’s are crossed. Have all invoices been delivered – and paid? Is the issues list signed off and complete? Have you checked the detailed project schedule again – are all deliverables signed off and accounted for? Have you touched base with the customer – are there any unknown outstanding issues or concerns that should be discussed prior to solution handoff? Are there any final outstanding questions or concerns from the subject matter experts (SMEs) and end user experts on the customer side? Those are the ones you need to make sure are ready for solution handoff.
Summary / call for feedback
This list is really just the tip of the iceberg of what the business analyst really does on the typical technical project and implementation. Did I say typical? I’m not sure if there really is such a thing as a typical technical project – it’s never that easy or containable. But the BA role is so incredibly significant and broad that what they end up touching is literally everything. This list just covers a few very key areas of involvement. And as far as ping pong goes… play away. I love ping pong and I’m very good at it… just not sure I want to hear it all day or have others playing it in the workplace, but I’ll get over it as long as I can find a good place to work that has a solid core door on it.
Readers – what do you think about this list? Do you agree with it – what would you add to it or change about it? What is your corporate culture like? Very casual? Too casual? Just right? Please share your thoughts and discuss.