Monday, April 30, 2018

A crash course in project management


Introduction

A project starts as soon as you have a team of people working towards a goal. The naive approach is to start emailing backwards and forwards. This results in a mess of transactions that hides important patterns. Adding in some shared documents, say using Google Docs, only creates greater confusion. This quagmire is avoided by structuring work through project management software.

But which app? There are several overlapping categories of software, and within each category are dozens, if not hundreds, of potential solutions. This article will help simplify, by explaining the core concepts and defining terms. If you are new to project management, this article should save you a few dozen confusing hours.



What a project is... and isn't

Let me start by giving an overview of different classes of software.

Individuals often start the process of organising their work by using a time management app. This software helps you track deadlines, make to-do lists, etc. These apps are focused on small tasks, on individuals.

Workflow software assists you in tasks that do not have a definitive end date. For example, I decide I want to write a blog. I am going to start now, but the work will be ongoing. Writing a blog is not a project, but can nonetheless benefit from management.

The most popular example currently is kanban, a method that began in Japanese automobile manufacturing. The core component of kanban is a visual representation of your tasks as cards on a surface of fixed size. Every card represents a task. Because the space is limited, you can only have so many tasks in front of you at a time. This focuses your attention on the tasks that have the highest priority, preventing cognitive overload.

Typically the surface is divided into three columns: To Do, Doing, and Done. As work happens, a task moves from left to right and is then archived.

Kanban is also an example of collaboration software, since most implementations are designed for teams. Specific individuals are assigned the tasks and they have dependencies. This is reflected in sophisticated kanban implementations in two ways. First, custom columns allow you to monitor tasks that are Blocked, At Risk, etc.



Second, tasks will be divided into different rows, termed swimlanes, usually representing different team members. The overall kanban is hence a grid. It's perfectly suited to managing ongoing work.

Collaboration software generally focuses on communications. This includes discussion threads, live group chat, audio and video meetings, document stores, annotation of documents, versioning, etc.

Intranet software extends these tasks into a full social network for employees, facilitating sharing and collaboration. These huge programs are designed for large companies where the up-front costs and ongoing maintenance can be justified.

Time management, workflow management, collaboration software, and intranets are not project management. Nonetheless many PM apps include some or all of these useful features, in order to create a unified workspace.

Projects are different in having a specific beginning, end, and goal. For example, though a blog itself is not a project, writing a specific blog article is. I might begin the article today (Monday) and need to have it finished by Friday. Every article is on a specific topic and has specific resources assigned to it.

Compared with the other tools, PM apps are more highly structured. This structure requires some setup time, but pays off.

So, what elements make up a project?


Project team and roles

Every project has a team. Experience has demonstrated that small teams work best, though how small depends on many factors, including the proximity of the members, the scope of the goals, and the importance of individual tasks. For software development, 3 to 4 people might be best. If you examine the contributions to open source software, it often turns out that three or four people do most of the work. But for design projects you might instead see a team of 6 to 8 people.

The Ringelmann effect shows that if there are too many people on a team, contributions for each individual become lower. It's easier to hide on a big team, and defer work to others.

Of course many projects are much larger. This requires that the work be divided up into smaller teams, each with a tighter scope and more limited goals. These small teams then aggregate into a complete workforce.

Even in a distributed and collaborative environment, it is best if the project has a manager, a person tasked with keeping everything on track. Though every contributor should help with management, "the buck stops here" is nonetheless a good principle. If you wish to be more egalitarian, a given team can rotate leadership roles with each new project.

There are other important roles on a team. For example, one person might be an expert on core technology. Another could be the documentation writer or chronicler. A third, the presenter and main point of communication. Sometimes it is best if these are explicitly assigned; in other cases this is not necessary.

It is a principle of many design processes, including Agile methods, to include the client in the process as an active agent. PM software often allows the creation of guest accounts, and the ability to restrict permissions and manage privacy.


Time and task management

The second chief resource is time. A project must have a realistic completion date, with provisions for overrun. The more projects a team has done, the better they will get at estimating this date. The time factor is also a matter of how much work each member will be expected to do each day/week/month. This depends on whether they are devoted solely to this project, or have other obligations.

The natural tendency is to wait for a deadline before working flat out. This is why numerous small deadlines, or milestones, need to be set. Plan on incremental development towards quantifiable goals.

These milestones will have dependencies. Some work can be done in parallel, but in other cases one task (e.g. testing) must wait for another (development) to be complete. It follows that tasks should be assigned priorities.

It is convenient to be able to schedule recurring tasks, or create templates that can quickly be re-used. Subtasks allow simple hierarchies to be notated.

An individual should be able to see their tasks in various ways, including a kanban display. Meanwhile, managers require dashboard views that integrate the entire team's work, flagging any important delays or missed milestones.



A Gantt chart is a particular bar chart that summarises a project schedule. Required tasks are listed vertically, with time on the horizontal axis. It's easy to tell from the width of each bar how long a task will take. Important milestones are marked. Dependencies can be indicated with connecting symbols. Furthermore, the colour or shading of each bar indicates progress to date.

Gantt charts were once an essential part of project management, and are still likely the single best visualisation of a project's path. However, many apps have adopted more casual approaches. As a result, Gantt charts might only be available in the most expensive version of a given app.


Other resources

Other resources include computer hardware and software, office support, and so on. A budget itemises all of these. It is important to cost out all expenses before you begin, since the last and most important resource is... money.

For this reason time tracking and costing might also be included in PM software, even if this is not, strictly speaking, a project management function. Timesheet software requires every team member to allocate their time (usually in quarter hour increments) to a given project and task. A manger can then see which projects are going over-budget, and also what percentage of time is billable, what percentage is overhead.

If required resources are not available, there will be productivity bottlenecks. Sometimes these are unavoidable, but it's important to know where they are and when they fall in the timeline. Managing a project is all about managing expectations. Every project is a success or failure on its own terms. A project that achieved a lot in one month with 50k budget is more successful than a project that missed its goals over a year after investing a million and change.


Conclusion

As you can see, everyone means something different when they talk about project management, a potentially vast area that touches upon every business function. This summary has introduced the key terminology. Future articles might summarise feature sets and examine the available apps.

RELATED POSTS

1 comment:

robin said...

This article has been updated on my Patreon page. Over the next week, two extensive articles will follow. The first provides a checklist of PM features. The second compares 17 available products.

https://www.patreon.com/robinparmar

Post a comment