Project Management Software Development: A Fresh Look From a New Perspective

Human behaviors are complicated to measure. There are so many variables in how we react to different situations that quantifying our behaviors in a way that can be illustrated with a graph or spreadsheet is problematic. The best way to understand how people interact with the project management process would be to borrow from the science of anthropology—and observe. Observing how users interact with project management software is the best way to learn how to make improvements in the user experience. However, that’s not the way most software, including project management software is designed.

Typically, development follows a more iterative process, which usually looks like this:

1. A need is identified
2. Software engineers create a version (or solution) to meet the need
3. The version is shared with a focus group (which could include both internal and external participants)
4. Feedback from the focus group is collected
5. A new iteration incorporating the feedback is created
6. The version is shared with another focus group
7. The process continues until the software is considered complete

This seems like a fairly logical process, right? It might be logical, but it isn’t the most effective way to create products that better serve user needs and it never results in anything innovative.

As opposed to an iterative process, "Qualitative research helps us understand the domain, context, and constraints of a product in different, more useful ways than qualitative research does," writes Alan Cooper in his book About Face: The Essentials of Interaction Design, "It also helps us identify patterns of behavior among users and potential users of a product much more quickly and easily than would be possible with quantitative approaches."

In other words, when designing software, what users think they need is not always the same as what they really need—which is one reason project management software is so complicated and difficult to use.

Most project management software is a great example of the traditional software design process. The common paradigm for project management software today looks at the repeatability processes of the assembly line created during the industrial age as a model for how projects should be approached. Although Henry Ford developed a very effective model for building cars, it is not a very good model for the creative problem solving that goes on within project teams by knowledge workers. Which is part of the challenge associated with how today’s workforce interacts with project-based work.

The traditional approach to PPM software development has created software that includes numerous features requested by customers and analysts, without any real validation as to whether or not those features add any value to the process—or are really even needed by customers. What’s more, contextual inquiry, or observing how people interact with the project management process generally and the software particularly, is the key to designing software that will meet the needs of users and fully engage them in the process.

Solution providers (like AtTask) who utilize contextual inquiry to actually observe how people interact with the software are more likely to create solutions that are broadly accepted, readily used, and adopted throughout the enterprise.

Are we there yet? No.

However, we are well down the path of better understanding how the workforce interacts with PPM tools and where we need to improve our product. Our focus on social project management and the introduction of Stream earlier this year are great examples.

Feel free to share your thoughts on contextual inquiry and the software development process.