I've outlined here what I feel are the 6 most critical things that the business analyst needs to know or find out at the beginning of each technical project. Not always in detail – that may not be possible. But at least in as much detail as is possible. Let's examine and discuss.
Related Article: 5 Things Your Project Customer Assumes You Know
Is the tech team ready?
This can mean a lot of things, but what I'm focusing on is this; is the team fully assigned and ready to go when needed?
I realize that this is more the call of the project manager as it is usually that individual's responsibility to see to it that their team is assigned and ready when needed. But since the business analyst's key role is to liaison with that team, then they are also involved in that process. The business analyst needs to assist the project manager in making sure that the right team members are available when needed on the project. Preferably not too early but certainly not too late.
Are they technically equipped for this engagement?
The technical project is going to need a particular mix of technical talent to get the job done. As the key tech liaison with the technical project team, the project manager is going to rely heavily on the business analyst's assessment of the technical capabilities of the assigned project tech team. Do we have the right talent? Do they understand the chosen technology? Does anyone on the team need training to get up to speed? The business analyst needs to assess this and aid the project manager in making these things happen so that the project can move forward.
What state are the requirements in right now?
How well are the business processes and project requirements defined coming into the engagement? Many clients will come into an engagement saying they've already defined the requirements – hoping to keep costs low. However, 99.9% of the time you'll find that they are way off in their assessment of requirements “completeness.” Requirements need to be detailed, complex, and very complete. They are basically the basis for all work going forward. The project manager needs to assess the requirements status and plan the project schedule accordingly, but the technical business analyst will be able to give a much better indication of the state of the requirements and how much more effort will likely be needed to get the requirements fully documented and signed off.
Does the customer have training needs?
It's a technical implementation and requirements need to be completed with the customer's input and eventually the customer will need to be leading the way in user acceptance testing. Is there any training – on the technology being implemented or on the customer product that is being configured and implemented - that the project client needs in order to complete the business process review and the requirements definition process successfully? After all, no client can really help the delivery team document requirements if they don't understand the solution. I've found on many occasions that customer training is needed and that changes the project budget and timeline. But it is far better to assess that and make that correction up front rather than later in the project.
Do we likely have the competence to implement the necessary technical solution?
Can the team pull this project off technically? Can the organization? Sometimes a project is just not the right fit, no matter what a sales or account manager who signed the deal says. And the best time to make that call – rather than fail miserably – is at the beginning of the project before any real work starts and any real budget gets chewed up. Sometimes it's just a tight fit, and some training may need to happen. That's ok as long as it doesn't hurt the timeline and the delivery organization takes on that cost if it wasn't in the original scope of the project. However, sometimes the fit is never going to happen, and that tough call must be made. Once this is realized, talk it over with sales and senior management before throwing in the towel as you want to not only do it right, you want to make sure you've exhausted all options before you raise the white flag and surrender. Let senior management make that call and break the news to the customer...they approved the project in the first place.
Does the schedule seem doable? Most schedules are pretty tight. And after an early assessment of the project, the team, any training needs and the technology needed for the solution, the business analyst should be able to make a fairly reasonable – and accurate – call as to whether or not the initial project schedule seems doable. What you need to know from the outset is this; can you win on this project with this schedule – and with this budget? Is it possible or will it be impossible? You may not be able to make that call, but you likely can once you know the above information. At least with some reasonable degree of confidence. If you need more time for the project, the best time to negotiate for that is at the beginning. Later on, it will just look like you're failing.
Summary / call for input
I'm not saying the business analyst needs to know everything...just like there is no way the project manager can definitely say everything is in order on the project at any given time. However, this list of six key project elements are usually well within the technical business analyst's knowledge base, and they can make at least a good call on where the delivery team stands on its ability to implement the right solution for the project client. And really, that is what we need to know before we get started because it will affect everything going forward -the timeline, the budget, etc.
What about our readers? What would you add to this list? What would you change about it? Business analysts, what do you see that is missing or that you don't agree with? Please respond and discuss.