TL;DR

This post starts a series of posts about project management. Passionate software tester must understand project management to be able to blend software testing into the process. The post is based on a remarkable book written by Johanna Rothman, Manage It!.

I found out about Johanna from Michael Bolton’s blog Developsence, and I put in my RSS reader her blog Create An Adaptable Life. She writes how to adapt our life to change. Her most famous book Manage It! opened my eyes about project management, and I would like to share with you what I learned from that book.

Let’s be honest, we all have hated our project managers at some point in time. The blame is on our ignorance about project management understanding. The project manager could not do it alone. We also must contribute.

In project management, you manage project risks.

Even in the preface of the book, I started my learning journey. From context-driven testing, we all know that context matters. You can recognize context-driven tester because it would answer your question with “It depends…” or immediately shooting you with follow up questions inquiring for more context information.

Each project is unique.

At the project start, you need to evaluate the project, the project team, and the business.

We have three types of projects:

1. software project
2. tangible project
3. services project

The tangible and services projects are easier to measure the project because project delivery is a tangible (real, solid, visible, stable, sustainable) outcome or report on delivered service. In a software development project, you can not see the outcome. For example, the result is not the web page but the software that generates that page (HTML + CSS). This is why it is hard to measure the project to unfold.

An example of a tangible project is to learn how to solve the Rubik cube.

This book will try to help you with managing software project risks, to have insight into the project, and to set meaningful metrics that could help you see the direction of your project. It is not about best practices, but about heuristics that could be helpful in some contexts.

Heuristics are a fallible mechanisms that could help you in simplification or solving your problem [Bach, Kaner].

And remember that a software development project is a non-linear system. You will change and create new decisions to adapt to new project risks.