Project management: What keeps you from loving flowcharts?
Project management is full of processes. Without the determination of processes, stages, steps, and stakeholders, it is almost impossible to get things done, especially under time and financial constraints. During the discussion of project management processes, team members usually have to depend on certain tools that visualize and convey their ideas. Flowcharts are probably one of the most common means of expressing processes without breaking their chronological and logical orders. Every project manager must be very familiar with creating numerous flowcharts for his/her/their many meetings, either by simply using pens and whiteboards or preparing them with graphic software.
Project and product people used to not question the use of flowcharts, but that has changed recently when we move into the era of information. Technologies cause things to move faster, provide better access to resources, and keep us updated with changes. As a result, many professionals, including leading experts, start to think we may waste our time and effort drafting a large of number of flowcharts that become irrelevant very quickly.
The long-standing issues
A decade ago, software engineering methodology pioneer Edward Yourdon already pointed out that flowcharts were becoming less popular in system analysis. One of the reasons he came up with are arguably also a criticism towards the use of flowcharts in project management:
“Though automated support (with PC-based drawing tools) is now available, it still requires considerable work to develop the graphics of a flowchart. And if the user’s detailed policy changes, or if the systems analyst has to change it several times before he has something that the user will accept as correct, it will be time consuming and tedious to redraw the flowchart each time.”¹
The modern agilist Scott Ambler also raised similar concerns about the use of flowchart though he found certain benefits of flowcharts as they can help people “think things through” and identify bottlenecks and dead-ends. In a piece of writing about flowcharts in agile modelling, he described working with flowcharts as a process that should be kept simple, require sketching on whiteboards then taking pictures or erasing them when they were no longer useful. This may be the reason why he did not use flowcharts frequently anymore and switched to more sophisticated types of diagrams to be able to brainstorm complicated processes.
Unfortunately, the increased complication can still be problematic. Large projects require a great number of actions; therefore, according to Scott’s words, activity diagrams can “get large very quickly” while the whiteboard space is limited. Notations can be another issue as a team needs to use a single system of shapes to make sure there will be no ambiguity. With the help of the Unified Modeling Language, we can minimize confusion. Nevertheless, this can be counterproductive for a project/product staff because the Unified Modeling Language can evolve over time, while the ultimate goal of a flowchart in project management is effective communication, not conformation to notation rules.
The many hassles of creating flowcharts may outweigh its advantages. People keep creating flowcharts to describe simple models, but become more and more afraid of applying them in critical and complex projects. The birth of visual editors have freed us from the boundaries of pens and whiteboards, but they do not solve the issues of multiple and time-consuming graphic adjustments and erroneous choices of notational symbols. Project management is currently “forced” to create and use flowcharts when that is a compulsory task, which has become a burden instead of a means of effective communication as intended.
What if it’s possible to automate creating flowcharts?
Creating flowcharts can be fun and empowering at the same time. That is our belief at code2flow. We understand the troubles project teams have to undergo when it comes to graphic illustrations. Therefore, we have decided to solve the issues of flowcharts that may have been accumulated and tolerated for decades. Also in his discussion of flowcharts, Edward Yourdon commented:
“If the process specification has been represented in some textual form that can be manipulated with a word processor, changes are usually much easier.”¹
He proposed a bold solution for the issue of flowchart content updating: changing visual elements using texts that can dictate the changes automatically. We are proud that our product code2flow happened to be the continuation of this suggestion. The utility of code2flow was predicted a long time before we planted the first seed.
Yes, the most outstanding advantage of code2flow is the ease of updating and saving changes with just a few lines of “text”, or pseudo-code to be precise. In addition, we build code2flow bearing in mind the headaches product/project teams experience:
- We base the pseudo-code on a classical programming language, to make sure the syntax can cover as many logical variations as possible. Only a user’s imagination can stop them from expanding and editing a flowchart in code2flow.
- Project teams will no longer have to bear the frustration of adjusting the graphics or the fear of choosing the wrong shapes. Everything is handled by the machine
We do not know if Scott Ambler has heard of code2flow yet, but we are pretty sure the product can deal with most of his concerns and be a good reason for him to enjoy flowcharts with a very fresh sensation. If you are that project or product manager who cannot stand creating flowcharts and updating them everywhere, you can enjoy the same by giving it a try here 😊.
The undiscovered potentials
While emphasizing the importance of a master flowchart in every project management process, Sonya Siderova, Kanban expert and founder of Nave, also considered that a flowchart is “only one cog in the larger project management machine.” This means a flowchart should be integrable into other tools, and connectible as a module of a project. Integration is definitely an untouched direction of development for flowcharts. Integration, in our interpretation, is not only the presence of flowcharts as embedded illustrations. It should enable real-time synchronization of objects and their analytics. The code2flow team is determined to take the initiative to lead this development path, and we have been doing so by introducing and researching features like live embed, API access, and real-time collaboration.
Ambitious as we may sound, it is the reality that we need to illuminate project/product teams first on the immediate benefits of creating flowcharts using a textual interface: less time spent on creation and adjustment, a unified language, and the ability to expand and complexify without limits. There will be challenges that we are still trying to find out. We cannot do better without hearing from our audience. Therefore, we would like to ask: project and product people, what keeps you from loving flowcharts?
