| Every project has leaders. There are project managers, analyst leads, developer leads, and architects. Each adequately meets their portion of the software development lifecycle. What's somewhat easy is coming up with their job descriptions, what difficult is defining their correct relationships.
I thought I would take a moment to try.
Introducing project roles
Some roles are obvious. Many SDLC methodologies (MSF, XP, Scrum) have gone before us to help. Using these, I will indicate the bare necessities. I do not mean no others may be necessary, but that these are.
- Executive Sponsor
- Business Sponsor (or Product Owner/Scrum)
- Subject Matter Expert (or Stakeholder/Scrum)
- Business Advocate (or Business Liaison)
- Project Manager (or Scrum Master/Scrum)
- Functional Architect (or Lead Analyst)
- Business Analyst
- Manual Tester
- Technical Writer (or User Education Specialist/MSF)
- Technical Architect (or Solution Architect/MSF)
- Technical Lead (or Lead Developer)
- Developer
- Build Master (or Release Manager/MSF)
To be clear, these roles are universal. It doesn't matter if you handle project with waterfall or agile approaches. In order to marshal project efforts, the roles in that list are necessary duties.
The all-in-one
This begs the question: which roles may be assumed by a single person? Some small (often freelance) projects have one team member. Cost, time, or other factors make this inescapable. In so, I concede roles may be shared – but this does not become a recommendation. The situation is extenuatory, like a single athlete running all the legs of a relay.
Sharing roles sheds duties
Review the roles list again. Consider the quantity. In medium-sized projects, simple cost makes "sharing-roles" a practical requirement. Here is a small project's "shared" role setup:
- Executive Sponsor, Business Sponsor, Subject Matter Expert, Business Advocate
- Project Manager, Functional Architect, Business Analyst, Manual Tester, Technical Writer
- Technical Architect, Technical Lead
- Developer, Builder
Here, four fill all roles. Whenever two things are merged, something of each is lost. No one expects either to be fully the same, any more than two glasses of water poured into one remains the same volume. What is lost, however, can be selected; job descriptions address this.
Role Interaction ORM
[image needed]
The interaction of different objects (roles) in the project, guide us in selecting which may be shared by a single member. They also help indicate conflict between roles and potential overlap. I am not suggesting that you limit intrapersonal communication. The ORM indicates the duties of communication.
Role Organization Chart
[image needed]
It is difficult to communicate the importance of a project organization chart as part of any project's charter. However, it is. Defining such relationships post-problem is laden with pitfalls and spawns issues deeply set in human personality. The project charter sets expectations and settles the matter.
Apparent authority
Now consider who directs whom, how decisions are made, and how ties are broken. Although the final authority lies in the Executive Sponsor, and subservient authorities are clarified by the organizational chart, we are remiss to remember the following truths:
- Those in authority are not made so because they are the best
- Those in subservience are not made so because they are the worst
- Authority is neither power, nor superiority of mind or innovation
- Project teams are made of real people with personalities and feelings
- Every single project benefit from team continuity
Each truth could be its own book. But each should be inserted as part of a project's culture. Mutual respect, regular communication, and regard are necessary part of human interaction. Still, progress is better than consensus. A project's endgame is a product, not friendship.
It may be difficult to "remind" other members of your authority over them. Confrontation is awkward. But "paralysis by analysis" is real. Discussions eventually need to end. Decisions need to be made. And depending on the level of the leader, they see this earlier.
Conflict
Most project conflict stems from ambiguous authority. Is the business, the architect, or the advocate the final say? In our need to be needed, we can promote our ideas intensely. But a project organization chart and detailed job descriptions defuse these conflicts many months before they arrive.
Action items
What can you do? Start with a project charter. It's essential to define success and describe the project, the goals, and the team. Don't forget a list of roles, job descriptions, and an organization chart. And, be dedicated to establishing the project culture. Not just fun and just high-quality, but respectful with a clear understanding of roles, and why you've set it up the way you have. |