• Our take on Project Management

    Kilian Muster

    Aug. 15, 2014 at 06:50

    I have been managing small to large scale projects for the past decade. I’ve come across what I consider three main approaches to project management tools:

    • Issue/Bug Tracking with some support for communication about the issues: Trello, Lighthouse, RedMine, to name a few.

    • Communication-based with some concept of To-Dos: BaseCamp, Jive, TeamBox, and the like.

    • ​​More “serious” project management, with attention given to managing the meta data of tasks in order to give more managerial views of the project: Jira, MS Project, and others.

    I started with simple issue tracking and communication tools for managing projects within our company. And while often very good at what they did, I often had:

    • Little clarity about where I was in a project
    • Unsure when I would be able to deliver a feature set
    • If I was over budget or under budget on a project (e.g. if we were being paid properly for our work).
    • How much time we had spent on a project or feature set

    At first I thought it was because I needed to “upgrade” to a more full-featured project management tool. However, after each experiment with a new more serious tool, I ended up going back to a simple issue tracking application. 

    Why? Perhaps the strength of more serious PM tools is also their weakness: as they attempt to gather the meta data they need for managerial level views, they tend to be form-based with many attributes to fill out, leading them to be bothersome to use and difficult to adopt (get everyone to use the tools). And even after all of this, I found they often did not help me answer the questions I listed above. 

    So, we always returned to the simpler Issue/Bug Tracking tools. While these were the best of the bunch for us, I felt that there was still much wanting in the project management space and room to do something innovative. Something that could be configurable, but structured, could be communication-based and easy to use while still capturing the essential information for reliable project management.

    Specifically, I felt that the following could make a difference in allowing people to manage projects better:

    I. Bundle a strong communication tool together with PM features.

    Communicating in one place and managing the work to be done in another does not work well.

    You end up linking or copying and pasting information from your project management tool to emails/other communication tools in order to ask the right people the right questions. Any friction in communication will result in fewer people asking the right people the right questions. This leads to more misunderstandings, wasted time, money lost, frustrations, and inferior results.

    Work assignment and communication all in one place.

    II. Ask for the Right Information at the Right Time

    A task has a life cycle and the information that is reasonable to ask is dependent on the stage in its life cycle. 

    Does it make sense to ask for the time you took to complete a job before it has been worked on? No. Does it make sense to ask the user to estimate a job when it is completed? No. There may be a half dozen attributes that are important to a job over its life cycle, but there are rarely more than one or two that are important at any given time. With this realization, we could simplify interfaces considerably.

    III. Estimate Intelligently

    Estimation, if done, should be done consistently.

    Maybe you don’t believe in estimates. That’s fine, estimates can be enabled or disabled on a per-project basis. 

    For many, though, estimates can be very useful to assess the effort required to implement something so it can be put in relation to the value it provides. With these two values it is much easier to prioritize tasks based on how much bang (value) you get for the buck (time required). Does it look like this thing will take us hours, days, weeks, or months? Perfection in estimation may be a pipe dream, but getting a reasonable guess is a reasonable thing to ask for in a PM system.

    If you do use estimates, unless everything is estimated all other estimates become of questionable value. Having 80% of your tasks estimated gives you little more clarity than having 0%. So, one of our principles is: if you are going to estimate, intelligently enforce it systematically.

    IV. Track Time Intelligently

    Again, this is an option only for those that want it. But if done, it should be enforced systematically.

    Time tracking can be essential to get an idea where people are in a project and, in some cases, billing. Like estimation, it only works if it is enforced systematically and users are prompted for this information intelligently. 

    V. Prioritize on a Project Level

    Prioritization on a project level makes more sense than prioritization on an individual level.

    Why? Often, when work is done, the work needs to pass through more than one person’s hands. Unless work is prioritized on a project level, each person that touches the work will not understand its relative value to the project and the work will be susceptible to being re-prioritized or de-prioritized by each recipient.

    VI. No “Priority Level”

    As anyone that has received multiple ASAP requests knows, priority only makes sense in relation to other things you need to do. Are you going to do it 1st, 2nd, or 3rd? Everything can not be 1st.

    So, priority is supported: you can prioritize all works in relation to one-another, but “Priority Level”, in terms of “high”, “ASAP”, “Must-absolutely-do-now”, or whatnot are not supported. Again, if you really want them, you can kludge the Labels to do this for you, but we do not encourage this as these absolute priority levels are rendered meaningless with proper relative prioritization. 

    VII. Treat people differently depending on their role in a project or piece of work

    On a project-level, there is often a project manager. Project managers need to know what is going on throughout the project. This is a good opportunity to be noisy for the person who needs it (the PM), but to not bother everyone with things that do not concern them.

    On a task level, the system should treat you differently if you requested the work, are working on it, were involved it at some time, or are not directly involved in the work but are involved in the overall project.

    We address this in Qortex by being context and person-aware to streamline the interface and reduce noise, but still capture the essential information from the right people at the right time.

    VIII. Flexible, but Structured

    Tags vs Labels

    I’m generally not a big fan of ad hoc tagging by anyone on the project. I find it tends to the disorganized and messy.

    I do want the flexibility for the project manager to organize labels to classify their work in a way meaningful to the project. 

    With Qortex, we designed the system to be flexible in terms of classifying work, but requires that such decisions are deliberate.

    Flexible workflows within a defined structure

    We didn’t want to be too strict here, but did want some defined high-level structures in order to provide meaningful system-level automation and the ability to use whatever workflows make sense to an organization. We did this by defining 3 broad workflow categorizations: “Not Started Yet”, “Open”, and “Closed”.

    We then allow companies to map their own processes within these categories. By doing this, we can make the system smart by knowing, for example, if you are moving an item to a closed state that it should prompt you to enter the time you spent working on it when time tracking is enabled. 

    IX. Agile PM For Non-Developers

    I imagine if you are aware of agile development principles you have read the subtext: the system we have developed here is highly influenced by Agile/Scrum methodologies. By stripping out the lingo and making the system inherently smart, sensible, and easy-to-use, we are hoping Qortex can be an instrument for spreading agile project management principles to companies and departments that would normally not have the opportunity to learn about or use the methodology.


    Ever since we started developing Qortex I have been waiting for the day that we could integrate PM tools. If nothing else, I wanted to build the “ideal” project management tool to answer all of my personal longings and frustrations.

    I’ve already been using it internally for some time and I know it works very well for our purposes. I’m looking forward to seeing how its design and guiding principles stand up to PM in diverse environments. Give it a shot and let me know how it works for you and any improvements you would like to see.

     

next entry previous entry