• Analyst, Business Analyst, Requirements Specifier, Requirements gatherer, Use Case Modeller, Business modeler, Systems Analyst, Domain expert are all roles form the Business / Requirements end of development. Many of them have an intersection of common activities, but there are also some roles that have no common activities, unless there is a really small team and one person is doing the effective equivalent of multiple roles.
• Developer, Coder, Programmer, Implementer, Techie - once again all very similar, but subtly different in some cases. Typically, a developer implies more than a programmer or coder - they do Analysis & Design also.
• Architect, Data Architect, Information Architect, Business Architect, Functional Architect, Systems Architect - say no more!

The problem stems from the fact that there is a collection of related activities that people do as part of their job.

Person - activity: So looking in the class diagram on the right, one Person does many Activities. Of course, an Activity can be done by many People. e.g. Use Case Modeling Workshop typically may have John (a User), Mary (a Business Analyst), Pete, Harold (some requirements gatherers), etc. in attendance during a workshop.

Role -activity: A Role is defined by its make up of a collection of many Activities. Similarly, an Activity can be done by many Roles. e.g. Use Case Modeling Workshop. This can be done by Requirements Analysts, Architects, End Users, etc.

Person - role: One Person may have many Roles they play simultaneously because of someone being on holiday, or at different times in the project. e.g. Mary, who is a Business Analyst, can also double her role as a Requirements Reviewer on the team during the same iteration.

Team Size Matters

The issue is further impacted by the size of the team. Generally the smaller the team, the more Activities that have to be performed by a much smaller set of people. The assumption is largely that the base Activities do not reduce as the number of people diminishes on the project. One accepts that on huge projects, certain activities are done that in no way would be done on much smaller projects, but there comes a point where the list of Activities remains constant and is usually a much larger list than the number of people to execute these Activities.

Lets hypothetically assume that we reduce the same team. As the team shrinks in size, what happens is that Mary who was our Business Analyst on a much bigger project, gets to do all the Requirements gathering, Workshop organising and Business Analysis in a more agile process. We loose say Harold and Pete as requirements gatherers. Mary simply has to take up doing some of the Activities that Harold and Pete were doing when we were on a bigger team.

The point of this is Mary has always been called after her main role of a "Business Analyst", and on a smaller team she would be doing the roles of Requirements Gatherers, Workshop scribes, etc. Even if Mary did rename her role, it would still probably not describe the Activities she is responsible for to someone who had just come into the team.

Process Matters

Not only does the size of the team affect the Roles and Activities, but also so to do the particular Process Framework and Methodology we choose to follow on the project. What approach we are going to use for gathering requirements? Will we only do System Use Cases? Or will we also do Business use Cases? Will we build a Business Object Model either way? Are we going to document Business Rules separately? etc. etc.

The outcome of these decisions (and this was only a small snapshot of the Business & Requirements discipline of the project) will directly affect the Activities that are going to be configured for the project process and in turn who will be responsible and able (skill and experience wise) to perform them.

Getting Process Defined in Time to do the Iteration Matters

All very well spending all the time creating fancy plans for how the project will be done, but while the Project Manager is doing that, many of the rest are waiting. Or are they? No way! Most IT people I know are working away doing what they feel is best (in all good intentions for success).

Often by the time the Project Manager or team presents their plans, the rest have already done their own thing and are halfway through. And guess what? Very likely that it will NOT be what are in the plans! Then they spend the rest of the iteration trying to play catch-up and figure out what they have versus what they want and how they will get the team back on track. Sound familiar?

Peoples' Skills & Interest Areas Matter

There is another dimension to this worth considering; People's Skills and interest areas. If the Project Manager inherits a team of people, the task is to understand what there is to work with in terms of people skills and experience. Obviously, the Project Manager should try to maximise his staff potential to their best most experienced skills. Further more; also try and put them in areas they are very interested in working in, even if their skills are not entirely suitable, as self-motivation can be a huge driver for success.

Trying to obtain this information while the project is underway, can be disruptive, time consuming and from experience, rather political. People start wondering what the ulterior motives are for wanting to know what they know, especially when times are tight and people are being made redundant. Make sure people are told what the exercise entails and that training will be given where its needed, etc.

What the Real Problem?

I'm sure most people could live with the fact that I got confused when they told me they were a Business Analyst and it didn't immediately imply that they were also in charge of gathering and modeling all Requirements. So big deal! After being on the project for a couple of weeks, I'd soon get to know all the idiosyncrasies of the team and its interrelationships. Fine for a team of five or eight people. Any bigger and it starts getting to be a problem. Things start falling between the gaps, especially when everyone is under tight deadlines.

The real problem is that if the people themselves don't realise what they are responsible for, how are they ever going to get it right first time? This is where many errors creep in. "Oh! I thought Joe was going to write that code" or "I thought Mary was going to identify and model all the Actors." 

If we do anything, it should be to get the process for the iteration defined as early as possible (i.e. before the iteration starts) on medium to larger teams, then publish it to all concerned through a verbal presentation, then document it on the project web.

"I love deadlines. I love the whooshing sound they make as they fly by-" Douglas Adams

Suggestions

While there is no easy answer to this problem, there are probably some ideas that could make it a little easier to live with (probably more relevant for teams larger than about 10-15 people):

• It would be useful if there were an international standard set of naming conventions for roles and the activities they perform. RUP, as mentioned above, has gone a long way toward putting a stake in the ground to define these in some detail. Some other processes and methodologies have too, but there is still no real agreement. Lots of discussion on the forums though; which is good for the longer term.
• Teams should then map individuals onto a collection of Roles and selected Activities to which they had tailored their process to conform. I realise this is extra work and is not that agile, but just doing the exercise forces the Project Manager to think through the process and the work load on individuals.
• Map these Roles and Activities considering the skills and interests of the People on the team.
• This mapping could be put up on a central intranet for the project, and adjusted per iteration as things change. This helps to focus the team on:
  • What the overall goal is.
  • What the individuals are responsible and accountable for.
  • What their teammates are responsible and accountable for - so they know who to talk to.
• Another set of ideas that is coming out of the Agile and XP methodologies is to try to rotate people per iteration, so that they work on different parts of the system or sub-system. This makes for a bigger understanding of what's going on in the project and the code.
• The more this flexibility is implemented, the more we will need to be on top of who is doing what, so that we know who we should be talking to on the project. It's definitely easier to manage on smaller projects.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment