13

I'm working on a project that's very stressful and has high attrition rates. One of my client's main pain points is that the people working with them don't know their requirements and proprietary details to the level they'd like. In essence they don't understand the client's business processes or some the technical details of their set-up. It's important that they internalize business processes and documentation so that they can hold their own in process discussions. They should also do this quickly and efficiently so the more experienced people don't have to answer the same questions over and over again.

How can I get new colleagues to commit more details and processes to memory while minimising impact on experienced staff? Should I ask them to write stuff down and review their notes instead of consulting colleagues? How can I get them to take away more from meetings and training sessions than they are now? I'm considering also out-of-the-box suggestions such as making a set of flashcards and keeping it in the office to use like trivia.

  • 1
    Can you be more clear on exactly what knowledge is expected and why it's missing? Are they literally referring to "requirements" in an official sense (ie, referencing a requirements document that was signed on the beginning of the project)? Do they mean literal "requirements" but there never was an official document? Or is the expectation that staff would be more aware of the overall culture and foundations of the project - knowledge of business processes, responsibilities of different parties, who owns things, etc.? – dwizum Mar 22 '18 at 13:55
  • 1
    So would it be fair to re-phrase your question as, "how do I get my colleagues to learn business processes" instead of, "how do I get my colleagues to write stuff down?" Important distinction - people learn in different ways, writing things down isn't always a good way for people to actually understand or learn something. – dwizum Mar 26 '18 at 13:21
  • 2
    Ok - so really you're asking, "How do I onboard new technical staff and get them up to speed on business processes and technical details?" With a footnote of, "the few experienced people I do have are sick of explaining this over and over!" – dwizum Mar 26 '18 at 14:30
  • 1
    @Lilienthal The first option. I'd like them to internalize business processes and documentation so that they can hold their own in process discussions. – Hard Worker Apr 2 '18 at 4:21
  • 1
    @HardWorker Thanks for the feedback. I've updated your question significantly to focus on that first option and used some of the language from both your and others' comments to identify the core question. Please edit it further if I missed anything or changed too much. Despite the difficult subject I also think it makes sense to get a more canonical answer here so since your bounty auto-expired I've started one myself. – Lilienthal Apr 2 '18 at 12:36
16
+50

It's simple really.

Put a process in place that demands that projects are only worked on if there's a signed off requirements document. Whoever adds to that document during the project initiation phase also makes sure that whatever they put into it doesn't conflict with anything else.

Anyone working on the project after sign-off then tags each work item with the requirement step number.

Just working from memory and ad-hoc meetings is just going to end in chaos.

You really need some decent project management processes, but starting and sticking with a requirements/design document is a decent first base.

  • 2
    It sounds like you also need a project manager. These are not a bad thing and often are necessary as projects become larger and more complex. They will be the person that meets with the client and knows their requirements. They should have the authority to set schedules and priorities for the development team as well. In agile this role is known as the product owner. – Bill Leeper Mar 23 '18 at 15:15
  • Agreed. But starting with a requirements/technical design document is at least a start. – user44108 Mar 23 '18 at 15:18
  • I see the point of there being a product owner for this project. Sadly we've no such one person and it maybe makes sense to spread the knowledge among more people, given our attrition rates. There are technical documents but because they're split into modules the interdependencies are not obvious and are hard to understand. – Hard Worker Mar 25 '18 at 14:33
  • 1
    So why can't you document the dependencies as a section of your requirements/technical documentation and then collate these dependencies into a "dependencies" document as and when they're documented? – user44108 Mar 26 '18 at 10:26
  • 1
    @Snow Good suggestion! We're actually doing that as of a few days ago :) – Hard Worker Mar 26 '18 at 14:08
3

I would look at this from a slightly different angle:

It is rare (and a somewhat unrealistic expectation) to be able to drop new people into a complex project and have them be really productive in less then 6 months or so. Depending on your staff burnout rate you may do very much better to address the turnover issue rather then (or in addition to) the training one.

Why are you burning people out? Fix the attrition and most of this pain will go away.

High attrition is usually some combination of unrealistic expectations, hiring the wrong people, poor pay and benefits (Actually this is the least common driver), or poor project management and leadership. There is a certain truth that people join companies but leave bosses.

Now training, you need to get your subject matter experts to write documentation, and to explain why not just what when it comes to process issues. FAQs, some sort of intranet site for the documentation (Make it searchable and have an index!), do departmental (and interdepartmental) "Lunch and learn" sessions (We order in pizza, but whatever works).

  • "and have them be really productive in less then 6 months or so" That applies more to new hires joining a company rather than a client/project team who need to generate value almost immediately. I assume the OP is talking about onboarding time for client-specific info and not about new hires. Though I'm not actually sure so I'll leave a comment up above as well. – Lilienthal Apr 2 '18 at 20:30
  • @Lilienthal I have yet to be convinced that it generally makes more then about a factor of two or three difference which sort of "onboarding" (Dreadful abuse of English!) you are doing. What does help is trying very hard to find people with task domain knowledge going in, task domain knowledge trumps an intimate knowledge of particular tools and frameworks nearly every time (There are a few exceptions to this, but that is the way to bet). But I still say the real (and frankly the humane) answer is to fix the burnout problem. – Dan Mills Apr 2 '18 at 21:41
  • Well "onboarding" is now a commonly accepted word and a rather important one in a consulting environment, which the OP is in. Quickly adopting clients terminology, processes and standards is an essential skill for client-facing consultants who constantly move between clients. Improving retention will help but won't solve the problem of getting people up to speed with a new client environment. – Lilienthal Apr 3 '18 at 10:41
2

Snow's answer is great - and he's right on the money about getting a robust process in place around establishing requirements being really key.

I'd like to add however that in the more general sense of getting people to record the contents of meetings I think a good approach would be to get your colleagues to see this as something that causes a problem for them, point out that simply remembering the events and discussions of a meeting not only isn't working but also leaves them wide open to some "convenient" reinterpretation of memories and events by a client. Say your client swears blind that one of the team promised they could have Really-Time-Consuming-Feature A and they could have it yesterday - how would they prove otherwise? That sort of thing.

Once you have them seeing this as a problem that will benefit them to solve you'll probably find that they get a lot more proactive and enthusiastic about finding those solutions and implementing them.

Speaking of which here's some suggestions:

  1. Nominate someone to take notes

There is a reason that meeting minutes are such a cliche - they really do work. Having someone take brief notes on everything of import that was discussed in the meeting gives you a clear record. This not being the 1950s (thank god!) where everyone could just get someone from the secretarial pool to sit there and scribble away means that generally this falls to one of the meeting participants to do. The responsibility can be rotated around the various team members from meeting to meeting to ensure that no-one feels unfairly burdened.

  1. Record the meeting

Most smartphones will either have a built in recording app or one can easily be obtained from the relevant app store. While not as convenient as written notes a recording ensures that nothing gets missed and other than hitting a couple of buttons to start and stop the recording at the beginning and end of the meeting it places no additional work load on anyone during the meeting. Obviously depending upon your jurisdiction you may have to meet certain consent thresholds in order to be able to record a conversation but that's outside the scope of what Workplace SE can cover.

2
+300

First thing we do is establish a wiki for all the process details. Anytime someone puts in their notice, they have to to make sure the wiki is completely up-to-date on all of their responsibilities and to train someone currently in the office on those things before they leave. That person trains the replacement when he or she is hired and handles the responsibilities until the hire takes place. Now the new people have a place to go to understand the processes. They have a place to go review before a meeting, to be sure they understand what this area is about.

One of the biggest problems we used to have is that new software developers (especially contractors) didn't understand the business processes or why they were important. So we set up a training session specifically for that. We also ask them about the business processes in their current job when hiring to help identify people who are used to understanding the the meaning behind what they do. These people are more likely to care about getting up-to-speed on such things.

I have a training sessions specifically on data meaning that shows them why it is important to understand what the business is using the data for and why it is critical to understand the complexities of our database as it relates to the business. After they work through a few examples, they are much better prepared to understand that you can't just know how to use an ORM or a write SQL code, you have to understand what the results of queries mean. After all I can write a ton of different queries on the same set of tables and have the business meaning be totally different.

You can also ask the client to spell out specifically which things they feel that new people need to know to come up to speed quickly. Their list may be very different from what you would do for initial training. It could also help to have the business users of the software, produce a video where they go through different sections of the application and talk about what they do in that section and why they do it. We did a session like that shortly after I was hired and it made so many things and programming choices much more clear to me.

A key part of this is having your own management care about processes, requirements and business rules and modeling that behavior by explaining them as they go with new people, by asking them questions about those things when planning a new module, etc. You get what you expect and if you don't expect people to learn the business as well as the technical programming side, they won't. Every meeting that does not contain the client should also talk about these things. New people need to understand that they are important. In technical meetings, you should be looking for holes in requirements and then passing those questions up to the client to resolve (not make assumptions about what they want!!!!!) Any organization that cares about business rules and requirements pushes a very large portion of initial requirements back for clarification. If QA and the dev disagree about what a requirement says, it gets pushed back up for clarification, if the dev has a question about what to do in this situation not covered (requirements often only cover one decision side of a decision tree), then it gets pushed back. Devs will be less likely to pretend they are clear on the requirements when they see senior people pushing them back for clarification.

Code reviews should also look at requirements to see if the code meets the requirements. QA should base their tests on the requirements.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.