Project Process

There are two high-level convictions behind how DevMynd manages projects: the belief that visibility is essential to project success and that empathy is the path to solid collaboration. Projects with a high degree of transparency and communication (almost to the point of over-communication) always run more smoothly. When visibility is high, surprises are infrequent and issues are dealt with expeditiously. And, when the team is able to empathize with the customer and their business drivers they are able to align interests and collaborate more effectively on the highest value work.

Inception

The inception phase of a project is critical to setting a successful tone for the effort. There are three main goals during inception:

• Get the logistical, project management, and boilerplate things out of the way
• Create opportunities for the team to gel, internally and with the client
• Define enough stories for work to begin and create the project Roadmap

Project leads and managers will use the Inception Checklist Guidebook to validate that everything has been set up properly.

Kickoff Meeting

At the very beginning of a project a kickoff meeting should be held which includes everyone on the team (including the client). If possible, the practice lead and the account's client partner should attend. The goal of this meeting is for everyone to be introduced, and for the team to get an opportunity to hear about the business value of the project directly from the client. Here is a sample agenda for kickoff meetings:

• Introductions, briefly allow each person to talk about their role and background
• Overview of the business, not the project, but the client's business
• Overview of the project and the role the product has in the larger business
• Review the project roadmap and proposed timelines
• Set up project schedule (standups, IPMs, etc)
• Questions and answers from the delivery team

Project Roadmaps

Every project will have a high-level plan which consists of a series of milestones. This project plan is not set in stone, but is a living roadmap which tells the story of where the team has been and how far they have left to go. It should be the main tool used to communicate overall project status to a customer.

Milestones

Milestones are themed clusters of user stories which, when delivered will enable a particular user journey through the system. Organizing a project into milestones helps to demonstrate delivered value more clearly and gives the team regular wins. Milestones should be ordered from the onset of the project and rough target dates should be set for delivering them. The order can change as the stakeholders adjust priorities, but estimate targets should accommodate change.

Iterations

Iterations are 1 week in length, they begin and end with the iteration planning meeting (IPM) which usually occurs on Tuesday. Work done during the iteration should be planned intentionally, after IPM very little should be added or removed from the list of stories scheduled for the current iteration. If too much work is added, or not enough, this should be considered for the next iteration – accuracy is the goal.

Roles

Though a project may not have dedicated individuals for each of the roles on a project, someone must serve the function of each role. In general, the more separation between roles the better, but team size and project scope will determine whether this is necessary.

Practice Lead

The practice lead serves as the head of delivery for the company and will ensure that our common processes and practices are being followed, and that a high quality product is produced. The practice lead is also an escalation point for issues and will work with the client partner in matters of client management. Lastly, the practice lead will work with the sales team and the project lead on staffing needs.

Project Lead

Each project will be assigned a lead, in most cases this will be someone in a principal consultant role. The project lead is responsible for the quality of the deliverables, whether they be code, design, training, etc. And, the lead has the primary responsibility for defining the implementation solution. The project lead will work closely with the practice lead for staffing needs and to escalate and resolve issues.

Project Manager

The project manager's responsibility is to ensure that the DevMynd process is being followed and that customer visibility remains high. More specifically, the project manager is responsible for:

• Ensuring that stories are being written on time, ahead of when a developer needs them, usually in collaboration with the client and project lead
• Task assignment and estimation and ensuring that stories are completed on time
• Reporting project and budget status to the customer
• Running project related meetings
• Communicating team outages to the client ahead of time and highlighting impact
• Monitoring scope and making appropriate adjustments to estimates and timelines

In some cases the project lead and the project manager will be the same person.

Developers & Designers

Developers and designers on the project are there to execute on construction. In addition to merely writing code and producing design artifacts, they are the first line of defense for raising issues and maintaining visibility. Developers and designers should always know what work they need to be doing, any lack of clarity in requirements or tasks should be corrected or communicated immediately.

Client Partner

While the project lead is responsible for the quality of the deliverables, and the project manager is responsible for the project's budget and process, the client partner owns the relationship with the client. The client partner will likely be one of the practice leads or executives. It is important that this person not also fill one of the other roles on the project as there needs to be a clean and separate escalation path for issues. Further, the client partner is responsible for maintaining a good rapport with the stakeholders and will regularly explore future work opportunities with the client.

Meetings

While communication must remain open, clear, and frequent, standing meetings should be kept to a minimum with the exception of the following.

Name	Frequency	Who Attends	Duration
Standup	Daily	Entire team, including client	15 minutes
Story Writing	Weekly early in the project, tapering off as necessary	Project lead, and business stakeholder	30 – 60 minutes
Iteration Planning	Weekly	Entire team, including client	30 minutes
Client Checkup	Once or twice monthly	Client partner, stakeholder, optionally the project lead	30 – 60 minutes

Stand Up

Daily stand up meetings should be brief and focused on what was accomplished yesterday, what the plan is for today, and calling out any blockers. This is not a design meeting, it is not for story writing, and should not be planning. The project lead will strictly keep stand ups to their intended purpose. It is recommended that stand ups include the customer, ideally in person or over video conference. When customers regularly skip the standup meeting it should be called out as a project risk.

Story Writing

The purpose of story writing meetings is to groom the backlog and ensure that there is adequate work for developers both in quantity and quality. This is not a planning meeting, it should purely be for product discussions, writing new stories, adding detailed requirements, and removing unnecessary scope. Story writing meetings should happen in advance of iteration planning so that adequate stories exist to plan. As the project progresses and fewer stories are left to write/refine the frequency of story writing will decrease.

Iteration Planning

Iteration planning meetings (IPM) are primarily for discussing the tasks and activities that will be accomplished during the upcoming iteration though some consideration for future milestones may also be made. IPM should not be used for adding new scope or defining requirements, it should be for purely for estimation and planning.

About Estimation

We use a 5 point estimation scale: 0, 1, 2, 3, 5. Points generally should not correlate directly to time, they should be a measure of relative complexity. For example, a four point story should be roughly twice as complex as a two point story. As a project gains momentum, the meaning of points becomes more clear and more predictable, allowing velocity to be predictive.

Despite not tying time to points, we do have a general rule that no story should take longer than 2 days. Stories that are thought to take more than 2 days to complete should be broken down into smaller tasks. No card should be so large that it cannot be started, finished, and delivered within a two day timespan.

A final note on estimation: nobody estimates alone. It is important that estimates be a collaborative effort between at least two team members, ideally the whole team should estimate during IPM.

Client Checkup

Client checkup meetings are a regular touchpoint at a higher level than the implementation team. This meeting is set aside so that high-level status can be shared, issues can be discussed, and ongoing sales discussions can be had. The team is not involved, and project leads may only optionally be included, so that open and honest discussions can be had at an executive level.

Managing Work

Card Wall

The card wall (we use Pivotal Tracker) is the primary point of visibility for the project and thus should always be an accurate reflection of what has been done, what is currently in progress, and what's coming up. Anyone on a project, be they clients or DevMynd team members should be able to look at the wall and get a sense for the progress and state of a project. Further, the project management system should provide insight into when the project is complete.

Cards

All work for a project should be associated with a card. The status of cards should always be up to date and team members should only have a few things in progress at once – having 7 cards in progress is an indicator of a process failure.

Epics

Each of the project milestones should be set up as epics in Pivotal Tracker. This gives us a way to group stories together with tags for easier navigation. Further this allows us to visualize the completeness of each milestone.

Time Tracking

All project hours are recorded in Harvest and assigned to the correct time code (development, design, project management, etc). When team members are assigned to a project they are expected to record at least 35 billable hours per week. It is strongly recommended that team members update their time sheets at the end of every day while things are still fresh. Time reports should come with a 1-2 sentence description of what work was done.

Reporting

It's already been mentioned that we want to organize our process around visibility. To that end, there are a few things that should be updated weekly to encourage communication. It's best for the project manager to own this reporting and for it to happen at the beginning of each iteration, preferably before IPM.

Budget

For most projects there will be an initial estimate range (optimistic – pessimistic) and a median which we track to – this is usually defined during the sales process. Each week customers should be informed of how much budget has been spent and how much is left relative to the estimate. This should spur honest and open discussions about adjusting scope, which is the primary lever that can be used to control cost.

Roadmap Status

As mentioned before, the roadmap should be a living document. Each week the project manager and client should take a look at the roadmap and discuss overall progress as well as adjust prioritization at the "big block" level as needed.

Project Report Card

The project report card is an internal tool we use to get a week-by-week view of the health of a project. It should be completed each week by the project lead and discussed in the leadership meeting so that project or systemic issues may be identified and addressed. This should also identify potential talking points with the client.