It seems to have been fairly popular with our readers here so I wanted to address more potential questions that can arise for business analysts on the projects they are helping to lead. Customers have lots of needs, and the business analyst is likely their most frequent communication point on a daily basis – especially on the more complex technical projects.
This can probably be a never-ending list, and I will probably address more in a couple of months, but for now here are my next five tough questions for business analysts...
Can this be hacked – is my data safe with you?
Everything can be hacked – and in this age that can go for just about any data on any project you might be managing or working on at any given time. I know that sounds like a mouthful and probably sounds like a bad trailer for a low budget horror film, but it's true. If they aren't going after you, then it's because they don't care about the data you are managing or that your customer has in their data solution you are working on. Yet. But it can happen. 25% of my past and current customers have been hacked in the past year and affected in some way... though thankfully not due to my oversight and none have been very damaging to them... so far. But that can change overnight, and it is likely they will ask you on every project going forward that has some data element. Be aware, always manage hacking as if it is a real risk. You can't likely ever fully prevent it, but you can take precautions, you can make your organization's security team or CSO part of your project team that checks in from time to time and you can consider mitigating actions to take in case of a hack. Do it.
Am I going to get slammed with change orders?
Nearly every client worries about getting slammed with change orders even if they don't always mention it. You need to convey from the outset what your change management process and methodology is, and help them to understand the guidelines that will result in change orders being presented to them. And most of all, you must do a very good job of requirements definition and documentation and scope management. Yes, overall that is a project manager's responsibility. But who is managing the ongoing development work on a daily basis in the real world – beside the tech lead? That's the business analyst. Manage it well and keep the customer up to date on any potential needs that could result in change orders. They never like surprises of this kind.
Do you have the right skill set on the project team to pull this off?
The project customer is paying the bills for the project – so they need to know that those expensive resources have the right skills to pull this off. Especially if you are dealing with new cutting edge technology. The best you can do is comfort them by providing background information on the team and keeping the customer up to date on a daily basis on the project tasks and progress – especially the more difficult project tasks. Don't let them get that unsettling feeling that their solution is in the hands of questionable talent... even if at times the team may be learning as they are going. You can know that, the customer should never hear that.
Why isn't my project more important to your organization?
Your customer is going to want their project to be at the top of your organization's priority list. If they feel like – in any way – their project is less important than any other project in the organization or on your project plate, that can cause them great anxiety. Never let them think that you are being pulled away to other projects you are working on or that any of the team members are overloaded on any of the other projects they may be involved in. You can know that and juggle whatever you need to juggle to make the work happen and help the tasks get completed. But that needs to be behind the scenes and not apparent to the project customer at all times.
How can I effectively test this solution?
Project customers and testing on tech projects. It's a difficult mix at times. In my early project management days I was tossed into the fire right out of my role as an application developer to oversee most of a $50 million government tech program with very sensitive data and very necessarily deadly accurate output as it was always financial in nature. Part of that management was overseeing the testing portion of the program and system on an annual rollout basis. Preparation was long and thorough, requirements and acceptance standards were ridged, and the incoming government testing team was needing and opinionated. A difficult combo. I learned early on that not all testers are created equal. You can not do the testing for them – that would be unethical and a definite conflict of interest. But it is everyone's goal to get through it as painlessly as possible so help them. And when they ask this questions show them how to write test cases and test scenarios, be available 24/7 to answer questions and hold hands and never be afraid to steer them back on track. They know you're the expert. And most customer end users don't care about the details, they care about the correct outcomes.
Summary / call for input and feedback
Again, the bottom line is we want to turn over successful projects. Our project customers are nervous and inquisitive if they are involved. Be ready with the right answers to keep them confident and keep them from micro managing.
Readers - especially business analysts - how do you feel about this list? Does this match your experiences? What would you add at this point? Please share and discuss.