Bonus Blog: Know the Players (Don't Hate the Game)

When you're running a project or managing people who are doing a project, it's important to know the players:

1) Stakeholders: These are all the folks (and I do mean all) that either feel they have a say or actually do have a say in what goes on in the project. Some people might define these more narrowly, but generally, this is a large group that has to agree on the business needs/requirements or no project happens.

2) Product Manager: Sometimes part of the stakeholder crowd, product managers have a variety of duties and/or titles depending on where you work/look. Often they are engaged at the early levels of a product to shape everything from marketing and packaging to actually gathering the high level business needs/requirements. Sometimes they're called "product owners" in Scrum/Agile methodology, but it really depends on how much refinement they do and collect regarding requirements.

3) Project or Program Manager: Typically, I think of program managers as those who manage collections of projects, usually under a specific theme, though some people recognize senior project managers the same way. These are the folks that take what requirements there are from the business (by meetings, collecting written materials, requirements, etc.) and turn them into business requirements that are the start of what developers, artists, UX/UI designers, etc., can work on. Sometimes, they do not do this role, and instead farm it out to Business Analysts. Regardless, whether they do that or not, Project/Program Managers manage schedule, resources and scope of any project.

4) Development Manager: This is the person who manages developers. Sometimes they are more active on a project and make specific decisions. Most of the time, they provide agreed upon standards for all developers and enforce them. They also handle the daily/monthly care and feeding of the people whom the manage. Sometimes they are a Developer Lead (and the group of devs reports to someone else for management) and they still do either specific project development lead work and/or standardization and technical help for the other developers. Sometimes the Dev Lead is treated like a Dev Manager, where they are also responsible for daily/monthly care and feeding of all developers. The Dev Lead or Dev Manager, or a Senior Developer will go over the business requirements document (and any attempts by Project/Program Manager and/or Business Analysts) and help break the work into technical requirements.

5) Architect: This can be several people; an architect can be an architect for business intelligence systems (how data is handled, entered, ordered, and reported on), for technology (how all the systems including this latest project are plugged in together and meet all standards/needs for the platform in the future), or if you're literally building something, physical architecture. Typically there can be more than one architect consulting on a project, but typically it's per specialty; rarely do two tech architects both consistently weigh in throughout a project. The role of the architect can be anything from someone who reviews designs and approves that nothing is beyond the ordinary, from someone heavy into the construction of the project at the very beginning and who occasionally monitors progress until the end. It really depends on the work being done and the time available for the architect to provide expertise.

6)Operations/Systems Administration/Production/Release Management: Depending on the org and the type of project, these are the folks who maintain what is currently live in production, and move any changes into the live system. They also maintain that system, review security (usually in conjunction with testers), and may handle permissions to access specific machines, utilities, etc. Their overall schedule is not tied to the project schedule, though the project schedule is tied to when they can help move code or work between environments or locations, and when they can help launch a project. They also provide subject matter experts on hardware, software, security, and a variety of other very handy topics which should be considered BEFORE the entire product is completed. Their requirements are frequently as mandatory if not more so than stakeholder business requirements, because they control the medium of launch/publication: you don't meet their requirements, your project never finishes. 

7) Project Team: This is the group that does the work. Usually this includes the Project/Program Manager and/or Business Analyst, a Product Manager/Product Owner, a Dev Lead or Manager, a group of developers and/or testers (Some teams have the devs do the testing cycles), UI/UX folks, designers, subject matter experts, etc. It can be expanded from the those immediately doing the software or building the hard ware to include folks doing the legalese, packaging, distribution, etc. Note: the architect might be a part of the project team, but often isn't completely dedicated to the project, so, often is not. Sometimes Operations/Systems Administration/Release Management will assign someone to work on a project, but more typically they are consultants brought in and sometimes treated like stakeholders (see above about not launching without meeting their requirements).

I'd like to take a moment to note that I was a Quality Assurance Tester, Lead and Manager for a large portion of my life, and they are awesome, required people. I have included them in the project team and not called them out specifically because many companies are moving away from a purely testing model to one where developers and testers share roles (and or swap them). I have not forgotten them, and I do, completely value them (or else several of them will come for me and I will be killed and this will be my last blog post), but I'm not pulling them out on their own for this particular project overview, though I will in the future, I swear (please don't hurt me).

There are a few other roles that sometimes come into play:

A) Patron - This is (usually) the single executive backing/pushing for this project. Consider them the stakeholder with the highest weight given to their requirements and needs, because without them, your project could get cancelled.

B) Other BigWigs - People at the level of your Patron, or at least above you, that may interfere with and/or poke at your project, because they can. I typically try to treat them just like any other stakeholder and/or direct them to my Patron rather than telling them to leave me the hell alone, which is kind of my preference, but typically the fastest way to get them to NOT leave me the hell alone.

C) Clients or Users - The people, in theory, for whom this product has been designed/created. Sometimes its an external client who is paying you for a service or a project, other times its an internal user who needs to be happy with a service or project in order for the project to conclude before you die.


Now you know the players! A future feature will go through RACI (Responsible, Accountable, Consulted, and Informed) and talk about how these all fit together so that we can have a happy project (or at least one that isn't chasing it's tail).