Subscribe via RSS Feed

The Role Call: A New Practice to Set Your Team Up for Success

The-Role-Call-ChecklistLast post I wrote about how often we begin a project from a disadvantage right from the start. Usually it’s because the team doesn’t have the resources or the commitments it needs from outside of the team.

In this post, I want to talk about a new best practice I am experimenting with. This practice is  designed to help set teams up for success by focusing on the project team resources. I call this best practice: The Role Call Checklist.

Key Roles On a Project

First I need to  explain the common thinking on key project roles: Specifically, every project is made up of 4 key roles. In no particular order, these roles are:

  • The Architect: This is the person responsible for the technical solution. For example, “does it work or do you get 404 or blue screens of pain”?

 

If the final application doesn’t technically work, or if it doesn’t meet a non-functional requirement, such as scale, then the Architect is accountable. I am not going to follow up with the Project Manager. It’s the Architect’s responsibility.

  • The Senior Business Analyst: This role is about  understanding what business problem this project addresses and, from a business point of view, what is success. Business Analysts are the proxy for our business users.

 

If the final solution works technically, but doesn’t do what the business needs, and doesn’t allow the business to achieve their goals, then the Senior Business Analyst is responsible.

  • The Senior Quality Analyst: QAs are responsible for the quality of the solution. Before everyone jumps on me, I don’t want to get into the discussion of exactly what the QA role is and how encompassing it is. I am a true believer that the QA role is larger than a testing organization. Their job is not to simply test and place a sticker on the software saying “Inspected by #12”.

But for this post, I hold the Senior Quality Analyst accountable to identify what quality the system holds.  What are the defects and is the system compliant with the intent? If the system technically works, and if it was designed to meet the business needs, then the Senior Quality Analyst is accountable to say whether it is ready to ship.

Finally,

  • The Project Manager: The PM is responsible for overall transparency.  This person needs to have an accurate picture of where we are in relation to schedule, budget and meeting Business Objectives. Further, they are accountable to serve the team by helping to identify and, more importantly, facilitate removing obstacles that can prevent the team from being successful. They are the manager.

Although I believe every project, small or large, has the need for these four roles, they don’t necessarily need to be four separate individuals. On smaller projects, you may have a single individual playing the Project Manager and Business Analyst role.  Or you may have the Business Analyst playing a Quality Analyst role. It depends on your culture and the strengths of your team members.

But the need to define:

–        What you are building,

–        How you are building it,

–        Whether you built it properly, and

–        How you’re managing the process

is required on every project. When a smaller team doesn’t believe they need each of these roles, it can create a gap to successfully delivering a solution.

And this brings me to the new best practice I am experimenting with:

The Role Call Checklist

I create a mini-checklist for each these roles. Under each role, I write what the role is accountable for. While there probably will be a common list of  responsibilities across many of our checklists, each role will also have some unique views.

If you are assigned a new project, I recommend creating this checklist to determine who is playing each of these roles.  On a smaller project, you may have one person playing two or three roles.  On a larger project, you’ll want to  identify the key owner of each role.

Then, I recommend that you meet with your team and make sure you are all in agreement as to who is doing what, and what the team is relying on each person for. I believe this small exercise can help a team start more successfully, especially when resources are scarce.

If you have a checklist, I would love to hear from you and find out what works and what doesn’t.  Does it make a difference?  Are you willing to share yours?  Feel free to add a comment below.

Tags: , , , , ,

Category: For Practitioners, Team Dynamics, Team Performance