Project Management Best Practices at Grio

While we don’t believe one size fits all, through the years we have developed some strong preferences about what works best when managing projects.

Grio follows a project management process that is loosely based on scrum / Agile. For the majority of projects, we use:

• Internal Project Kickoff Meetings (IPK)
• One week iterations
• Weekly iteration planning meetings (with clients where possible)
• Daily scrums (with clients if they want to attend)
• Backlogs organized into user stories
• Internal Retrospectives

Internal project kickoff meeting (IPK)

We’ve found that the best way to get a project started on the right track is to make sure that everyone has all the information that they need up front.  In order to make sure all designers and developers are coming into the project with the correct information, we hold an internal project kickoff meeting (IPK) at the beginning of a project. Every project, no matter the size, starts with this meeting. The purpose of the meeting is to transfer information that has been gained in the sales process to the project team before they begin working on the project. During the meeting, we document any promises made to the client during the sales cycle. We make sure everyone understand the project objectives and articulate any risks in the project, such as a tight timeline or new technology.  We review the project timeline, the staffing commitments we have made, any deadlines etc and we also review the project team & stakeholders on the client side.

Sprint / Iteration Cycle

We like to plan out work for a project in 1 week timespans, called  “iterations”.  At the beginning of the iteration, the team is given a chance to estimate the work for the coming week, and at the end we give a demo of the work that was completed – usually the demo of the prior week and the discussion of the next week takes place in the same meeting.  We have found that a one week iteration is enough to get something substantial work done & show progress, but not so long that a project can get too far off track, if, for example, a requirement has been misunderstood.

Project backlog organized as user stories, bugs, and tasks

The concept of the product “backlog” should be familiar to anyone who has worked in an Agile environment before.  The backlog is a prioritized list of all the things that need to be done in a project.  In the backlog, new features are phrased as user stories: “As a _____, I can _____”, for example “As a new user, I can sign up for an account”.  User stories should (of course) be user focused – ensuring all the user needs will be met.  The stories should be small in scope – each story should be able to be completed by one developer in a single iteration.  They should be written in language that is easy for anyone to understand.  Often, user stories are generated quickly during a meeting or discussion and can be fleshed out in more detail later.  We expect that the backlog will change throughout the project- new stories will be added as requirements are discovered and bugs & tasks are added and prioritized as necessary.

Regular meetings

Almost all of our projects utilize two types of regular meeting, the daily scrum meeting and the weekly iteration planning meeting:

Daily stand-up “scrum” meetings

These daily meetings are conducted in the classic Scrum style of answering 3 questions: what have you done since the last meeting, what are you doing today, and is anything blocking you?  The primary purpose of these meetings is to bubble up any problems or issues to project managers & to the rest of the team, and to make sure that everyone is working on prioritized tasks. These meetings are always short – 10-15 minutes at the most and often considerably shorter.  To keep things on track, stakeholders are discouraged from asking questions or talking until the meeting is over.  We strongly encourage clients who want to be involved to attend these meetings.

Weekly Planning Meetings

During the weekly planning meeting, the team gives a demo of the work that has been done in the last iteration, usually by walking through each story.  Once this is done, we review and discuss the work that will be done in the next iteration.  Prior to this meeting the project manager, in cooperation with the client, will already have reviewed the backlog to decide what stories to propose that the team work on in the next iteration.   During the meeting, the project team should have a chance to dive into the stories.  They will be able to review and discuss requirements & designs, ask any questions, and try to uncover edge cases. We strongly encourage client stakeholders to attend these meetings so we can discuss the details of requirements with them and answer questions as they come up. Once the team feels that they fully understand a story, they will give it an estimate.  The backlog is often reprioritize based on the estimates, or larger stories are broken down into smaller component stories.  Sometimes once the the team begins to define a story it becomes apparent that there is not enough definition – in this case we pull the story back to revisit in a future sprint.

Retrospective Meetings

At Grio, we value a culture of continuous learning, which includes learning from our past projects.  At the end of each project, we hold an internal retrospective meeting to discuss what went well in the project, what didn’t go so well, and what we’d like to do differently in the future.  We have found these meetings to be extremely valuable ways to define what our best practices should be as well as identify issues and pitfalls we might avoid in the future.

I hope this blog post has given you a short introduction into Grio’s project management best practices – for any other consultants reading, do you agree or disagree with these?