A Guide to Job Sharing for Business Analysts

15937 Views
2 Comments
4 Likes

Business Analyst Job SharingWith the shifting economy, the changing needs of working parents, and workers' increasing demands for flexibility, job sharing is growing in popularity across almost all corporate job sectors. The United States Department of Labor defines job sharing as "two (or more) workers shar[ing] the duties of one full-time job, each working part time." It affords employees greater flexibility within their schedules, the ability to work part-time, and the option to telecommute. It also offers employers a viable option for balancing heavy workloads and retaining talent. Even if all of an organization's employees are full-time, should a project balloons unexpectedly and an analyst become overloaded, the option to project-share would enable an employer to tag a less-stressed analyst to jump in and share the load.

Of course, job or project sharing also poses a unique challenge - two employees must effectively be of one mind. The US Department of Labor goes on to qualify, "In order for a job sharing arrangement to be successful, however, both individuals must be able to handle the position as efficiently as one person." Fewer professions pose more potential hurdles to job sharing than that of business analysis. The work of business analysis is steeped in meticulous details, consistent communication, deep subject knowledge, and often painstaking revisions. An analyst must be quite detail-oriented to keep up with her own work__the concept of spreading it across two people and two schedules is daunting.

However, if job or project sharing sounds like a good solution for you and your organization, effective job sharing is within your reach if you plan carefully. Whether you start a project and hand it off, or take a project from another analyst, or collaborate with another analyst all the way through, these simple habits will ensure that job-sharing is a win-win for you and your employer.

Implement a mutual record-keeping system. This is the most crucial step in successful project sharing. It should include:

  • Common file locations. Know where each others' notes, requirements versions, and calendars are kept. Ideally, they should be in a shared online folder or site.

  • Common file naming conventions. Agree on the same naming convention for files. For example, a requirements document that Mary Jones revises for the third time on November 14 might be labeled: "3rd.11.14.09.MJ.doc." This naming consistency will enable Mary's job-sharing colleague to discern at a glance what the latest document is and when it was revised.

    Mary may choose to make all document edits with track changes on for her job-sharing colleague, John Smith, to review. If John reviews the same document on the 15th and has no information that would contradict any of Mary's changes, he might accept all changes and label the document: "3rd.11.15.09.JS.doc." Colleagues must determine what works best for them, but consistency is crucial, and more detail is always better than less. Similar conventions should be adopted for meeting notes, archived emails, diagrams, and so on.

  • Decide in advance who will take ownership of what portions of the requirements, and play to each person's strengths. If Mary is particularly good at interviewing and research, she may do the discovery and write the first draft of the business or functional requirements. If John has a background in programming, he may take ownership of the diagrams or technical requirements. Throughout this process, have your colleague review/proof your work. If you continue to follow a set pattern of responsibilities throughout each project, you and your colleague are likely to get better and faster at the requirements process, since you are always using the very best of both your skills.

  • Common calendars. If it's not possible to share an Outlook calendar, you should at least be copied on all of your colleague's meetings and reminders, and vice versa. You don't want to plan for your colleague to proof a document Tuesday that is up for review Wednesday, only to discover on Tuesday that he's not coming in.

  • Common notes. Ideally, this should be a more sophisticated and durable method than post-it notes on each others' desks. You want to create an ongoing record that you can reference weeks from now. One idea is to implement a notes document within any file folder that both you and your colleague check daily. Notes should always be dated and marked with the name or initials of the person who created the note. "11.14.09: Attended usability review at 10:30 this morning, and made resulting changes to user requirements. Please review and advise. – MJ." Or, some programs such as SharePoint automatically alerts whenever a document is updated, which would be ideal for a notes document.

Theoretically, even if you never spoke directly with your job-sharing colleague (which is inadvisable!), you could still know exactly where he or she was in each project if he or she kept excellent notes and files.

Know your stakeholders equally well. You must both know the all of your project's stakeholders, their roles in the project, and their levels of knowledge. It is not efficient project sharing to spend hours researching the answer to a question when your colleague would have picked up the phone and gotten it from a key stakeholder in a moment.

Attend each others' meetings and reviews. This may not always be possible with job-sharing schedules, particularly on projects where meetings become prolific. But if your schedule permits, partnering on discovery meetings and reviews is always helpful. You will retain a better grasp on each others' stakeholders and their input into the project.

Keep superbly detailed meeting notes (and post them to a common online area). Whether you are able to attend each other's meetings or not, you should create a meeting summary while the meeting's results are fresh in your head. These should not be cryptic, i.e. "Check with Liza on time-out issue. Remember cache Brian mentioned," but detailed. Consider a topic/solution or question/answer format:

Q. Quality Assurance representative Dustin asked: "What results should we expect to see if the customer enters incorrect data?
A. Project sponsor Debra answered: "A prompt via a pop-up box that the data does not match archives."

This format makes it easy for someone who couldn't attend the meeting (or attended months ago) to quickly get up to speed on what the project should entail, and leaves no room for interpretation. (Incidentally, sending meeting recaps to attendees' in this format and requesting their approval will also help eliminate ambiguity from your requirements.)

Keep graphic pieces within the purview of one person. A text requirements document may be easy enough to collaborate (as in the example above). However, the nature of diagrams and charts makes it difficult for two people to collaborate in fits and starts. If you start a state diagram, it will probably be a better end product if you finish it. Again, be sure that your job-sharing colleague reviews and understands it before exposing it to any other audience.

Consider a project wiki. If your project is diffuse with new terms, definitions, stakeholders, concepts, etc., it may be useful to keep an ongoing wiki to which you can both refer.

Understand that off-hours communication will occasionally be necessary. On days that you are not working, your job-sharing colleague may have to call you for clarifications. But the more you implement the above steps, the less frequent such calls should be.

If you think that job sharing may be a good fit for you, or that project sharing may be a good fit for your organization, ask your business analyst colleagues for their thoughts on implementing job-sharing. Once one or more of you are on board, go to your employer with a plan of how project-sharing can work effectively, presenting some of these ideas. A thorough plan will go a long way to convincing your employer that job sharing is great solution for ensuring both employee morale and project excellence.

Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com


http://www.dol.gov/dol/topic/workhours/jobsharing.htm
Ibid.

Like this article:
  4 members liked this article
15937 Views
2 Comments
4 Likes

COMMENTS

Leslie posted on Wednesday, February 17, 2010 6:57 PM
If you do not have these 2 issues sorted before inception of a project, no amount pf job sharing is going to prevent its failure.

#

Common file locations. Know where each others' notes, requirements versions, and calendars are kept. Ideally, they should be in a shared online folder or site.
#

Common file naming conventions. Agree on the same naming convention for files.

The major advantages that I have seen discussed FOR BA job sharing are:
# A senior analyst can help mentor a not-so-senior analyst.
# On-the-fly checking of work, prior to completing a document and distributing for review.

Leslie.
baldrick
Leslie posted on Wednesday, February 17, 2010 7:00 PM
Actually, reading the post again in a little more detail .. all are good points, but if you are not already doing all of these best practices, you are in trouble.

Leslie.
baldrick
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC