Please review: Project management guidelines (draft)

Discussions - Public
1

Hey team,

(ticket to log time)

As part of our processes spring clean, I wrote down a draft for Project Management Guidelines which I think should be read and used by team members who have the role of epic owner. Can you spare a few minutes to review my proposal? I think you’ll need 15-30 minutes to do this.

I initially wrote this for a potential dedicated “Project Manager” role, but this role instead became the Cell Supporter, and excludes tasks that focus specifically on project management.

For now, the guidelines include a single milestone, which is to include a complete project blueprint when taking on new projects. I think it’s a good starting point, and I would like to measure progress on this before adding more milestones.

My intention is to include these guidelines in the epic owner role description, so I would appreciate if a few of you could review/comment on the document! If you need to schedule a ticket, that’s perfectly fine — I’ll set the deadline for this to the end of 259a, which is Friday Nov 5th.

I’m keeping the work document private for now since we might discuss specific clients in the comments, but the handbook update will be public!

Thanks in advance, and stay cool.

5 Likes
2

@gabriel Thanks for this document. There’s a lot of food for thought here. I’ve added some comments.

One concern I have is that we just pruned a bunch of processes so I’m hesitant to have us add more for a while. There also seem to be things in your proposal that should be covered by our current processes but seem to fail for some reason and I think it’s worth examining those before coming up with new solutions to make sure we know why they’re not working.

I’d be curious to know others’ thoughts. There are some real important points you bring up here.

1 Like
3

Thanks to those who commented already. I simply wanted to ack the pings for now — I’m waiting for more to appear to read and process in batch, later this week.

4

Thanks a lot, @gabriel for preparing this, just a small addition that I personally want to know is how do we identify red flags about a client and how critical they are. This could help us to be more vigilant and organized.

I know this couldn’t be a one size fits all so I would like to know a few of the experiences that you had and how did we deal with them. :slight_smile:

Thanks again.

1 Like
5

Quick update on this: I’ve been ill and I won’t be able to review until next week.

6

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 :white_check_mark: (or no one complained)

  • Upgrading the foundational discovery document into a more “complete” project blueprint which is shared with the client, and contains:
  1. The technical discovery document
  2. A list of all stakeholders involved in a project, their role, and who can approve changes to scope/budget/timeline.
  3. 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.
  4. A resource plan (“we’ll allocate x hours/points/Full-Time-Equivalents per sprint”)
  5. A project timeline
  6. A communication plan, based on a template

Items that still need to be discussed :warning:

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?

3 Likes
7

Would it not be sufficient to have an epic description change history tab, on an epic that the client has access to? That would mean very little overhead for the owner.

It could mean standardizing creation of client accounts on Jira and duplicating tickets/epics like we do for LabXchange, but given the alternatives, I think it would mean the least amount of overhead.

1 Like
8

I had suggested making sure epic descriptions never remove old due dates but just mark them with strikethrough and maybe a comment. But I like your idea way better-- I didn’t even know this was an option!

1 Like
9

@gabriel Thanks for the proposals, and the brainstorm this generates! :) :+1: I’ve just done a pass on the document, and made some comments, mostly minor. The main one I had though is this one:

+1 to this question. We would only want to fix things that have been a problem, and problems big and frequent enough to warrant the additional work. We want to try to reduce the unnecessary overhead, not add to it if we can avoid it.

There are things that have been mentioned in this document that are important, but before enacting the changes, I’d like to see a list of corresponding actual past issues that they each solve – as well as criteria and a plan for evaluating the effectiveness of the changes within a few months.

@adolfo

That would be ideal (and related to one of the comments I’ve made in the doc), but using Jira to communicate with all our clients might be tricky – we don’t have them all in Jira, originally mostly because of the cost of user licenses in Jira, but now additionally Jira has deprecated Jira server and doesn’t sell user licenses anymore, even if we were willing to pay the crazy amounts they ask for.

10

Because we haven’t (yet) had problems with something doesn’t mean we shouldn’t plan ahead to avoid issues in the future (“no need for a seatbelt, I’ve never had any accidents!”) — but I see your point. And most of the proposal comes from issues we’ve experienced anyway.

Sure, I’ve created a task to do this.

1 Like
11

I guess this is one big reason why we’re looking to ditch it. :slight_smile:

In any case, I agree with the comment you made in the doc: we should just put epic descriptions somewhere else that can be easily accessed by us and clients. The only requirement I’d add is that such a place has to track the history of changes. Google Docs does that, and it’s already the default way we share discovery documents with clients. Its probably a reasonable, low-impact choice.

3 Likes
12

As requested, I added examples for each new item/task. Maybe you’ll think of others.

  • I’ve deleted the “Milestones” item, because they’re often not requested by the client, it felt superfluous, and I could not find examples of issues this would help resolve.

We haven’t yet reached consensus about the “changelog” item, but here’s where we are:

  • The epic description is where we find the latest high-level details of a project (Description, Scope, Timeline, Budget)
  • We said that epic descriptions should be accessible to clients
  • OpenCraft should be able to track the history of the changes made to the epic description (less important for clients?)
  • Google Docs (suggested by Adolfo) allows sharing and history tracking, but it means we have to duplicate information in both Jira and Google Doc.
  • I’ve suggested that maybe all we need to do is send a copy-paste of our epic updates to clients at every end of sprint. Some of us already do it. I think updates will be more relevant to clients than the more static epic description.

What do you think?

2 Likes
13

@gabriel provided a lot of good information that’s well-written. In his document, I tried to add some thoughts on an approach that may make it more tailored and useful to our developers.

2 Likes
14

I reviewed the doc, gave this some thought, and here’s a proposal which I think helps meet the overall objective while keeping things simple:

  • We update the epic description template to add a few key elements: stakeholders (to be nested under the “Roles” section, which btw already kind of covers that — I didn’t know!), a resourcing plan (to be nested under “Budget”), and a communication plan. I would also add an item in the epic description checklist to share the information with the client.

Also, I think Tim’s new epic update template answers our needs in terms of monitoring changes made to the budget, resourcing, or timeline, and ensure that those topics are discussed with clients.

These are all relatively small additions which, even bundled together, won’t require much extra work from developers, and will have a positive impact on our work.

What do you think?

5 Likes
15

Sounds good @gabriel ! Thanks for working to find a place for these changes amongst our existing processes.

2 Likes
16

… and the changes are finally live! Your comments are welcome.