Documenting High Level Process Workflow

Written by: Josie Borlongan • Edited by: Michele McDonough
Updated Jul 6, 2011 • Related Guides: Microsoft | Visio | Operating System

A technical project manager should include a high level process workflow that would show how the application should work and what the dependencies are. This workflow summary will guide not only the users, but also the technical support teams when they troubleshoot issues or problems.

Next up: Workflow Documentation ►

Key Components

Slide 1 of 3

When a technical or IT project manager works on a project involving a new application, it is important to always DOCUMENT...DOCUMENT...DOCUMENT. Completing certain documentations pertaining to the processes and status of the project are two of the most important documentations during the project planning phase. However, a technical PM should also give considerable thought to provide documentation that would be of high importance after the project planning phase. The most sought-after documentation in IT is a process workflow that would include what the key components are of the new application.

The high level process workflow should show context diagrams (showing data flows, main interfaces and dependencies). This process should be provided and viewable by technical support, developers, architects, risk management, compliance and security teams as necessary.

Components:

Operating System: Would include the operating system used and version. For example, Windows, Linux, etc.
Application Server: May include apache or weblogic server components. The development and support teams should provide architecture at a component level of how the application integrates with an apache or weblogic server. Include all application services and internal system components and how they interact with each other.
IIS and other Microsoft Components: Should include .NET, COM components and other Microsoft specific dependencies that the application utilizes.
Database Servers: Some of the databases may include SQL, Oracle and DB2. The workflow should include a data model.
Middleware Components: Should include components the application should be dependent on, such as NDM transmissions, Autosys, AS400, etc.
Data Feeds: Should include all internal and external data feeds--- file transmissions from vendors using a third party application, etc. This may include key batch jobs from upstream/downstream dependencies. Should include how those feeds are sent and received.
Security and Authentication: Include what authentication process to use. For example, Kerberos, single LAN authentication, etc. Will there be a separate or second page authentication needed after the first one?
Network Components: Include information on switches, routers and firewalls.

Workflow Documentation

Slide 2 of 3

click to enlarge

There are certain applications that a technical or IT PM can use in documenting workflow processes. The most commonly used software is Microsoft Visio, which can show each key component with a different icon. Visio can map out and should show dependency arrow and connection.

Use Microsoft Excel to provide columned descriptions and functions. For example, to show the detailed information on the flow from Visio, use Excel to describe each component. Create one column for each key component and provide descriptions. For example, in a networked environment include information such as IP address of each system, DNS name of the servers, source and destination IPs, etc.

After completing the high level process workflow diagram and the documentation attachment, make sure to meet with the project team composed of the architects, developers, systems support, database support, application support, network support and key business proponents. Perform a review of the workflow, make updates or changes as need, and then have each one sign off after verification.

Workflow Repository and Distribution

Slide 3 of 3

After the technical teams complete signing off the workflow documentation, the technical project manager should save the master copy in a data repository. For example, some companies use third-party applications such as CyberArk, which is a vault system to keep documents safe. If preferred, the technical PM can use a shared server, provided permissions accesses to be granted are restricted. Some technical PMs use SharePoint to upload and share workflow diagrams.

Should a larger audience needs to view the workflow documentation, make sure to save one for public view that is sanitized, which means the doc should be devoid of security information, passwords, IP addresses, etc. in order to avoid compromising the integrity of the data and the application. This is important to prevent hackers from obtaining security information.

Avoid sending unsanitized workflow processes via email. If it is unavoidable, a technical PM should make sure to distribute only to a limited number of trusted people and add add data encryption and password protection. A technical PM should remember to keep the safety and security of the company as the top priority at all times!

◄ ●●● ►