Tying It All Together – Part II

Previously I briefly mentioned the types of tools that help technicians with analysis, design and coding tasks, and discussed their shortcomings as applied to project management and tracking. Today I will discuss tools designed specifically for project management and tracking and why they miss the mark.

Most project management tools are designed around the concept of managing large complex projects with critical resource, organizational and dependency issues. Microsoft Project is an excellent example. Tools like this are great for building bridges and sky scrapers which must follow an extremely prescribed process from beginning to end. However, for small to medium size software development projects, they are not appropriate. Software projects require flexibility at many levels that make these more sophisticated project management systems unwieldy. Also needed is the ability to make clear relationships from requirements to features and project tasks, with the ability to easily change requirements or change their relationship to both features and project tasks. Another missing piece with existing project management systems is the ability to track and manage bugs that crop up during the testing process. Having to use a separate bug tracking system just further disintegrates management’s ability to easily control and track the progress of any project.

Another category of tools that has been touted for project management are like whiteboard, allowing users to click freeform all kinds of project documentation, drawings and notes in a collaborative space. Although this whiteboard metaphor does provide a much more flexible communications between team members, it lacks the ability to impose any structure on a project. Products like Basecamp provide the ability to create task lists but they lack the ability to create project hierarchies, or establish dependencies between tasks. Now it may sound like I’m making an argument for rigid products like MS Project. What is really needed is a blending of the two, with much more flexibility then is available with products like MS Project while allowing a user to create some structure when needed. In addition, we need the ability to track requirements cleanly with flexible associations to the project. We also need the ability to track bugs and communicate about them with other team members.

There is still another important piece missing that I haven’t mentioned, but is just as important. As project managers or small to medium size projects, we need the ability to easily prototype screens and navigation in an online collaborative environment. This technology is important for two reasons. 1) Prototyping helps us to communicate our understanding and our implementation ideas to our customers, getting buy in quickly before designers waste any time creating mach ups. 2) Prototyping helps us to explain requirements and implementation concepts to developers before they waste any time building it wrong. The problem is that there are no good prototyping tools. The few I have seen take as much time to prototype as it does for a designer to mach up screens. None that I have seen are collaborative in an online environment. Most companies who have tried to create a good prototyping tool end up making it way too complex, with the idea that if the user creates a sophisticated enough prototype, they can use it to generate code.

I don’t know about you, but I have not desire to generate code from a prototype. I want an online prototyping environment where I can literally draw screens, widgets etc. while my customer or team members are watching and easily couple screens together to illustrate navigation. It should be easy enough to use that it doesn’t feel like extra work that later thrown out. Once a prototype is detailed enough, I also want to tie specific elements of the prototype to both requirements and project features. Then developers will be able to quickly display a visual reference to any requirement or project task. Software development would proceed faster with much more confidence. If a piece of the prototype changes, it would be easy to see which requirements and project tasks would be affected and need to be updated as well. The opposite is also true if a project task were to change. It would be easy to see what requirements and what other tasks might be affected.

Are you frustrated like I am? If not please let me know how you address these issues. The last part of this series will examine what Tekyz is doing to address these shortcomings.