Thank you to everyone who read and commented on the doc. Your comments were extremely useful and underlined two concerns:
Some suggestions and items found in the doc are overkill, or just don’t apply to our situation (relatively small project size, Agile development, etc.). A lot of the project management methodology was written to help huge, bureaucratic organizations where information doesn’t flow easily — which thankfully isn’t our situation. So let’s not adopt any processes that are not necessary for us.
Developers (and epic owners in this particular case) already have lots of overhead, many processes to follow, and many lists to maintain, so we need to be mindful of this and avoid adding any unnecessary tasks for them.
Here’s the breakdown of items that seemed to generate “consensus” and therefore should be adopted:
Should be adopted (or no one complained)
- Upgrading the foundational discovery document into a more “complete” project blueprint which is shared with the client, and contains:
- The technical discovery document
- A list of all stakeholders involved in a project, their role, and who can approve changes to scope/budget/timeline.
- A list of project milestones (when relevant): a significant point in time in a project where we’re supposed to have delivered x amount of deliverables against x% of the project budget.
- A resource plan (“we’ll allocate x hours/points/Full-Time-Equivalents per sprint”)
- A project timeline
- A communication plan, based on a template
Items that still need to be discussed
Change tracking / project document updates
Project management principles suggest that we track changes made to the project, and maintain a log of the changes. The idea is to document the evolution of the project, and ensure that OpenCraft and the client have access to symmetrical information. The assumption is that symmetrical information helps with managing expectations, which in turn to fewer misunderstandings over the course of a project. This seems like a no-brainer, but managing information and expectations turns out to be quite an art.
However, there are legitimate concerns about the amount of additional overhead generated by this process. If we implement a new process, it needs to be light.
What do we track? We work in an Agile setting, and lots of parameters change all the time. As I was reminded by a few of you, tracking granular scope changes is out of the question. How about we simply keep track of changes made to Milestones, project Budget, and project Timeline? We actually already do this in the epic description — but in most cases the changes aren’t committed to a document that is shared with the client. Which brings us to the next point:
How do we track it? Do we maintain and update critical project information (such as milestones, budget, and timeline)?. If so, do we update the blueprint (which is shared with the client), or do we just track changes internally at the epic level like we currently do?
IMHO tracking changes just internally brings the risk of information asymmetry (and potential misunderstandings) between us and the client. And we deal with some of that on an occasional basis. But I don’t know for sure if updating a shared document would resolve any of that. Still, ideally IMHO we’d update a document to which the client has access. But I don’t know if the team will think the additional effort required is “worth it”.
The idea here is really to make sure that OpenCraft and the client have a common understanding of where the project is. It might be that we collectively decide that implementing a new process for this is overkill, that the risk is not worth the added overhead.
What do you guys think?