23 November 2010

You Make the Call: Dave leaves the project

Dave’s role was the second business analyst on a large multi year software development project. His main role was taking the lead work the primary BA gave him and converting it to documents that would be later reviewed by both business stakeholders and the vendor.

Dave’s work was about the detail, the follow through and ensuring the BA work conformed to the enterprise quality standards.

His partner in crime, Sheila, was the lead BA. She was the visionary, the big picture thinker and the personal networker. She brought people together and unified them so that they were all focused on the project goals. He strengths were in the people things and she did a great job of it.

Sheila, in the first few weeks of the project had scheduled a series of workshops with the project stakeholders and then followed up with interviews and coffee shop meetings relentlessly until she had earned everyone’s respect and trust by demonstrating an understanding of their stake in the project outcomes and empathy for the costs and difficulties they were going to face together as the project changed the existing state of play in the organisation.

She was charismatic and full of energy. She had a natural charm that enticed the stakeholders into a conspiracy where they were all in this together and would all share the weight of responsibility for project outcomes.

Dave’s job was to follow up, document, test the ideas and validate the details with people. It was easy work as Sheila had enlisted people into the vision of project. Everyone was invested in its success.

Dave cruised through the days wondering at Sheila’s fantastic performance wondering if he’d ever be as good an analyst as Sheila. Sometimes he wondered whether he was even needed on this project. It felt like all he was doing was taking Sheila’s notes, although it was true that he did occasionally spot logical gaps or conflicts in business rules and occasionally highlighted functional deficiencies. But for the most part Sheila was awe inspiring and Dave really did wonder whether he would be missed.

When development began the same sort of things started to happen. Sheila started off by bringing in the whole development team from the vendor and giving them a presentation about the company’s mission and purpose and how the new system was going to contribute. She clearly broke down the scope boundaries on the product and explained why some very appealing and easy to implement features were to be deferred. She talked about the key features and how they would be elaborated over time to fully round the solution out over several releases.

Dave supplied everyone with the documented details to complement Sheila’s PowerPoint and presentation.

Sheila and Dave stood in front of everyone and took questions. The more experienced developers asked a series of detailed questions about features and target benefits, about how certain user interactions were envisaged. Sheila and Dave took turns answering them, Sheila often leading in with an answer and then deferring to Dave for the detailed follow up. Sheila knew all the answers, but was very encouraging of Dave and wanted him to get the recognition he deserved for the work he had done in modelling out and developing the system specifications.

The project kicked off and Sheila went into stakeholder management mode while Dave stayed in close and regular contact with the developers. Dave answered questions and checked in with Sheila daily on where the dev team were and what sort of things they were asking about.. Sheila shared feedback from the stakeholders, occasionally directing some minor change to a user interface or some elaboration of a feature.

Things were going well. The developer team were picking up momentum and building a great product. They were feeling thrilled to be working on a project with such a good client team. Clear about what they wanted, easy to talk to and flexible when it came to minor details.

The Dave got the call. His mother was ill and was probably going to die. He had to take leave and disappear for a while, possibly months.

The project manager, Karen and Sheila got together to talk about how they would handle Dave’s absence.

Here are the facts;
  • Sheila and Dave both knew the specs and the maturing solution very well, but Dave knew much more about the details
  • Sheila was also at her best doing the big picture-people thing and would feel stifled and frustrated pouring over specs and test cases, besides the project stakeholders constantly need contact and it took almost all of her time to keep everyone informed about where they were and aligned to the project goals
  • Hiring someone new now would be a challenge. The market was tight so there could be some time to get a suitable person. And it would take weeks for someone to come up to speed. 
  • There were only about 10 weeks until the next major release. This was the third release and the team tended to pump them out quarterly. There was a subsequent release coming up, and Dave had already done most of the spec work for that.

What would you do?


  1. Seems like a relatively low risk situation. I would rely on the developers' good understanding of the design and the good working relationship they had with both BA's so communicating on any issues that might arise does not seem to be a big concern.

    Am I missing something here before I dig myself too deep?

  2. This is why documentation is so important, because people do leave projects before they finish. If Dave has documented all detail needed by all audiences,then bringing in another BA, if one can be found internally or externally, should not take weeks to get up to speed.

    Given the end date is approaching, the documentation may be enough for Shelia to use when details need to be addressed. Certainly by this time I would expect the need to change details is minimal. So, perhaps Sheila can manage for the rest of this project (maybe some over-time) while a fill-in for Dave is found, certainly by the start of a new project.

  3. @Shim_Maron you're not missing anything. That was the actual solution the team used. Sometimes the obvious isn't so obvious.

  4. @DWWringt Dave - another viable approach. But as someone who does this regularly, what do you *usually* think when you peel open some previous analysts requirements work?

  5. Ah, the onus is on the organization to have standards about requirements documentation. If not, then confusion can ensue.

    What I see most of the time is pre-requirements docs: charters, project definitions and the like. If I am on the scene, it may be because any requirements work-to-date has not met the needs of stakeholders and development teams...so call the Fireman!