Who or what makes the big difference as to success or failure on a tech project? Is it the project manager? Is it the business analyst? The tech lead? The customer? The budget? The timeline? Luck? The skill set of the project team? 3rd party vendors? Unknowns? Issues? Risks? Requirements? Good or bad communication?
If I had to pick just one, I'd probably go with that last one since I think good communication is an absolute for any project success. But in reality any and all of these can and do contribute to project success or failure. That said, I feel strongly that a good business analyst is tantamount to project success as well. And here I am going to cover four tactics that a good, experienced and proactive business analyst can employ to help keep a potentially troubled project on track for the remainder of the engagement. Agree? Disagree? Or agree to disagree? Tell me at the end the who, what and why about how you feel about what I've presented here and let's see if we can figure this all out together so we can have some new strategies to deal with the pain that is the complex project problems experiencing issues and all have a better chance at a project win. It's all about sharing ideas and winning on projects, right?...
Take over the development team. The business analyst is usually the liaison between the project manager and the project tech team on development related projects. At least, for me, that's how I like to set my teams up as I already have enough overall project management responsibilities to deal with daily. They are also serving the same role in the project team ==> customer sponsor / team relationship. So, to go one extra step, the business analyst can and should fully take over the technical project team from a day to day task management aspect on a complex development project – especially if there are any issues threatening to push the project off it's rails. I'm not saying that proper oversight should be taken from the project manager – but there is enough organizational responsibilities and communication activities need from the project manager on a complex technical project. It makes sense to hand the project tech team over to the business analyst.
Have separate one-off meeting with the project customer once a week. As part of the customer service aspect of the business analyst role, this individual can and should have a separate status call with the project client - less formal in nature than the one led by the project manager each week that usually involves most or all of the major stakeholders in the project. The business analyst meeting should be just a one on one with the project sponsor or possibly also include the delivery tech lead and the client side top end user or subject matter expert (SME). In the most complex project situations, the project can even be adjusted to place that business analyst onsite full-time with the project client if that helps and if there is money available (budget or change order or otherwise) to make that happen.
Back to the meeting concept... this meeting should involve running through any key issues that are happening at the moment, a look at what's happening in solution development and what's about to start happening, plus any ongoing change order activity. This meeting will serve some clients' needs for more of an informal "let's get this done" approach.
Take over issues and risks discussions at each weekly status meeting. While the business analyst is conducting their own more casual project discussion with the customer, the weekly formal project status call would still be led by the project manager, of course. However, since the business analyst usually is the project team member most closely on top of the status of issues and issue resolution on the project, he could be and – therefore, should be – the individual leading that part of the weekly discussion with the team and the customer for the formal project status call.
Be the go to person for scope management. Another key area that the business analyst should take over as point person on is scope management. They are more likely to be working with the team and customer on day to day development activities as well as keeping any requirements documentation up to date as they are the ones working through any project change requests face to face with the development team and the project client. The project manager is still the overall project scope person and needs to know where things stand every step of the way in terms of project scope, change requests and change orders, but the business analyst will be the one creating change orders, tracking down tech lead estimates for the work required by the change order and then discussing the change order with the project client for sign off and work proceeding.
Summary / call for input
I'm not in favor of the project manager passing all important batons to the business analyst. But I do believe one of the key roles for the business analyst is serving as the liaison for all to the development team on a technical project. Given, then, that the business analyst is key contact with the dev team, then it also makes sense for them to lead the development team, lead discussions with the team on what they are working on each week, and lead discussions with the project client – and all key project stakeholders – concerning the status of what the development team is working on each week and the progress being made on those tasks.
Readers – what's your take on this list? Do you think a business analyst taking the lead on some of these responsibilities will help or hurt? Business analysts specifically – what do you think about this list? Can you give us some examples of when you've had to take the controls and help keep the project on track and what areas or actions helped the most or made the most difference? And were you too overloaded? Please share and discuss.
If I had to pick just one, I'd probably go with that last one since I think good communication is an absolute for any project success. But in reality any and all of these can and do contribute to project success or failure. That said, I feel strongly that a good business analyst is tantamount to project success as well. And here I am going to cover four tactics that a good, experienced and proactive business analyst can employ to help keep a potentially troubled project on track for the remainder of the engagement. Agree? Disagree? Or agree to disagree? Tell me at the end the who, what and why about how you feel about what I've presented here and let's see if we can figure this all out together so we can have some new strategies to deal with the pain that is the complex project problems experiencing issues and all have a better chance at a project win. It's all about sharing ideas and winning on projects, right?...
Take over the development team. The business analyst is usually the liaison between the project manager and the project tech team on development related projects. At least, for me, that's how I like to set my teams up as I already have enough overall project management responsibilities to deal with daily. They are also serving the same role in the project team ==> customer sponsor / team relationship. So, to go one extra step, the business analyst can and should fully take over the technical project team from a day to day task management aspect on a complex development project – especially if there are any issues threatening to push the project off it's rails. I'm not saying that proper oversight should be taken from the project manager – but there is enough organizational responsibilities and communication activities need from the project manager on a complex technical project. It makes sense to hand the project tech team over to the business analyst.
Have separate one-off meeting with the project customer once a week. As part of the customer service aspect of the business analyst role, this individual can and should have a separate status call with the project client - less formal in nature than the one led by the project manager each week that usually involves most or all of the major stakeholders in the project. The business analyst meeting should be just a one on one with the project sponsor or possibly also include the delivery tech lead and the client side top end user or subject matter expert (SME). In the most complex project situations, the project can even be adjusted to place that business analyst onsite full-time with the project client if that helps and if there is money available (budget or change order or otherwise) to make that happen.
Back to the meeting concept... this meeting should involve running through any key issues that are happening at the moment, a look at what's happening in solution development and what's about to start happening, plus any ongoing change order activity. This meeting will serve some clients' needs for more of an informal "let's get this done" approach.
Take over issues and risks discussions at each weekly status meeting. While the business analyst is conducting their own more casual project discussion with the customer, the weekly formal project status call would still be led by the project manager, of course. However, since the business analyst usually is the project team member most closely on top of the status of issues and issue resolution on the project, he could be and – therefore, should be – the individual leading that part of the weekly discussion with the team and the customer for the formal project status call.
Be the go to person for scope management. Another key area that the business analyst should take over as point person on is scope management. They are more likely to be working with the team and customer on day to day development activities as well as keeping any requirements documentation up to date as they are the ones working through any project change requests face to face with the development team and the project client. The project manager is still the overall project scope person and needs to know where things stand every step of the way in terms of project scope, change requests and change orders, but the business analyst will be the one creating change orders, tracking down tech lead estimates for the work required by the change order and then discussing the change order with the project client for sign off and work proceeding.
Summary / call for input
I'm not in favor of the project manager passing all important batons to the business analyst. But I do believe one of the key roles for the business analyst is serving as the liaison for all to the development team on a technical project. Given, then, that the business analyst is key contact with the dev team, then it also makes sense for them to lead the development team, lead discussions with the team on what they are working on each week, and lead discussions with the project client – and all key project stakeholders – concerning the status of what the development team is working on each week and the progress being made on those tasks.
Readers – what's your take on this list? Do you think a business analyst taking the lead on some of these responsibilities will help or hurt? Business analysts specifically – what do you think about this list? Can you give us some examples of when you've had to take the controls and help keep the project on track and what areas or actions helped the most or made the most difference? And were you too overloaded? Please share and discuss.
RSS Feed
