The First 4 Things the Business Analyst Should Know on a New Project
Know may not be the right word here…it may be more like ask. If there’s anything I’ve learned about projects in the past 25 years, it is this…if you need information, don’t wait for anyone to give it to you.
Ask for it. Demand it. Dig your heals and and don’t move until you have it. Hold a meeting to get it. Extend the kickoff meeting an extra day in order to get it, if necessary. But always try to get as much information about and for the project up front in order to help you down the path to a successful project conclusion. This is true for the project manager and it is also very true for the project business analyst.
So, let’s consider the first four things the business analyst should ask about or ask for or know when they are about to begin a new project. The project manager is the project leader and hopefully knows this information or at least has a good idea of it.
What the delivery project team looks like – skill set, etc.
The business analyst is the go-to liaison between the project manager and the technical team. Knowing what he has to work with on the technical side is critical information as he prepares for project kickoff and the next phase design work on the project. In fact, the business analyst, once he has a handle on the project and the requirements at least at a high level, then he should have some input into the make up of the project team. Usually the project resources are requested by the project manager based on the skill set needed and the roles that will need to be filled in order to complete the project effort. The business analyst would be a good – make that great – source to go to in order to make those project resource requests the best and most accurate they could possibly be. The business analyst knows the technical side and should be providing major input to the creation of the project team resources.
The customer team make up.
Likewise, knowing what the customer team make up looks like is critical for the business analyst as well. Why? Because the business analyst will be constantly interacting with the customer on various issues including clarification of requirements, work on change orders, questions about current and future business processes that affect or are to be affected by the project solution, user acceptance testing and what the end user community is expecting to see. If the business analyst has an idea of what they are working with early on in terms of the customer team formula, it will greatly help their planning and will likely have an affect to some degree on what resources are going to be needed on the delivery project team side as well.
What experience and infrastructure the customer has for the likely solution technology.
Are you using cutting edge technology on this new customer project or is it something both the delivery team and the project client are already familiar with? I realize that this is something you may not know completely until the final requirements are fully documented and the project is underway. But often the technology or process that will be used on the solution is known already or at least both sides have a very good idea. This information is helpful to the business analyst on the project for resource planning purposes, for requirements documentation purposes, for helping the client define their own project team and for helping the client define the “to be” business processes that the project solution will be implemented to. It is also very helpful to know this as any post-project technical support and training is being planned for and – again – these are things that the business analyst would be heavily involved in. The training may even be something they design and lead for the project customer.
The state of any high level requirements or business processes.
Finally, what is the state of the project requirements and business process definitions coming into the engagement. There are those clients who have done the work and know what they want, know what they need and have a detailed list of requirements a mile long. That can be a very good thing. It can also be a very bad thing. This type of client may “want” this, but unaware that they really “need” that. And it can be hard to convince them otherwise. Or, in the perfect world, maybe they have all those requirements and project needs documented correctly. Not likely…but maybe. Often times the project client has some idea of the need but it may only be a symptom or 80% of the real need. It’s up to the project team to figure out the real project and that investigation is really the responsibility of the business analyst. It may be led by the project manager and it may be acted upon by the entire team – tech lead and all – but at the end of the day it is the business analyst really leading this effort as they are working on complex, detailed, final documented requirements.
Summary / call for input
I’m not saying that knowing all this information at the outset will end in a successful project implementation. And I’m not saying this is all he needs to know either. But these are four key elements of input from the beginning that will help get the project started off on the right foot and help the business analyst to move forward more confident of a successful project outcome in the end.
Readers – what are your thoughts? Business analysts…do you agree with this list based on your project experiences. What are some other things you consider important to know up front as you move on to a new project? Please share your own experiences and thoughts and discuss.