It's all to do with the term Workflow. Workflow refers to the concept of taking a process and organizing the sequencing of that process including conditional branches. This is very familiar to project management people as the thinking is just like the flow of a project. Workflow software however has become all the rage and it has the potential to make a profound difference in project management systems when linked with databases, lists and, in particular: forms.
Think of this scenario. A new project manager is assigned to create a new project. He goes to the corporate Intranet where he clicks on "Create a new project". A form appears. He fills in the blanks. Depending on some entries he makes in the form, he might be asked for more information. He completes the form and submits it. Depending on other entries in the form, the approval process might be directed to one person or another.
This is the result of Workflow.
But wait, we're not done! The workflow engine also sends an email to the person who approves his kind of project. The pending project is put on a list of potential projects in the portfolio management system. A portfolio manager is notified by the Workflow engine that a pending project has been added to their portfolio and asks them to intervene to give it a priority.
The manager approves the project. The portfolio manager sets the priority and as a result, resource scheduling determines the schedule. The Workflow engine wakes up to these responses and sends an email back to our newbie project manager letting him know that his project is approved and telling him when he'll be getting staff to get it started.
Sound like science fiction? It's not. The tools for doing this exist right now. Microsoft has been promoting the Windows Workflow Foundation (WWF and yes, I know that's also the acronym for the World Wrestling Foundation) and how it links to their Infopath forms that are part of Microsoft Office SharePoint Server. Demonstrations that are now viewable of Microsoft Project Server lean heavily on this technology as a method of collecting and organizing data, and as a way of communicating with users in an unattended fashion. It doesn't take a rocket scientist to see that this kind of workflow is a future marquis feature for Microsoft and that it is likely to figure strongly in future versions of Project Server.
Are we stuck with Microsoft, though, to do this kind of thing? Absolutely not! If you've already got SharePoint Server in house, then you've bought the technology already, so you might not want to look elsewhere, but there are numerous workflow solutions in the open-source community. You'll find a range of possible solutions on SourceForge (www.sourceforge.net). For information on the WWF, do a search on any search engine of "SharePoint Workflow".
We've not begun to scratch the surface of what's possible with this kind of approach to collecting data. The beauty of it is the level of intelligence that can now be woven behind the scenes into the forms that are being filled out. Let's take our new project example.
The form could ask our new project manager to complete a "Risk Assessment" form if the value of his project is over $10,000 or if the duration is more than 26 weeks or if the work is being done for the government. The form could insist that this Risk Assessment form be completed before he even tries to submit his request for project approval.
The form could decide to send the request to a supervisor for approval if its value is less than $10,000 and to a senior manager if it's worth more.
The form could decide to immediately email the portfolio manager if the project is marked as "urgent" or if the executive sponsor is the CEO.
And so on and so on.
Notice anything here? I keep saying the "form could decide" but of course, forms don't decide anything and therein likes the rub. Any of the workflow we're discussing here has to be coded or programmed or defined in some way for the workflow engine to understand and that can be a challenge. In many of the project organizations I visit, the manual workflow process is ill- defined, not honoured or not defined at all. This kind of solution will demonstrate wonderfully and people will Ooooo! and Awwww! when they see it, but delivering the demo will take a lot more work. A lot more!
Just because the technology enables this kind of thing doesn't mean that organizations are ready to do the homework required to adopt it. I've been involved over the years in numerous workflow design meetings. In order to establish just one workflow process successfully, you need to bring together everyone who intervenes in that process now, as well as those who are clients of the process (meaning they receive the product that comes out of the process) and the suppliers of the process (meaning they provide input that results in the product). You have to look at all the possible permutations. You have to look at where the data will come from, all the possible actions you want to come out of the form(s) and process based on possible answers to questions and then you need to document, train, test and document some more. Yes, the potential efficiency improvements might be huge but you shouldn't trivialize the work involved in automating the workflow of a process even with great technology at your fingertips.
One of the other hidden pitfalls of workflow automation is the maintenance of this in-the-background-intelligence. What happens when the team that defined the workflow moves on to other things? Who will maintain the rules in the form and make sure they're adapted to changing business conditions? How were these rules documented? Who maintains that documentation? And, so on.
No matter what, you're going to hear a lot more about workflow automation in the year or two because it's just too compelling a technology to ignore and for larger organizations, automating any process that is done many times can result in huge efficiency savings but, like all of these tools, be sure you know not just the benefits but also the total costs before you start your own implementation.
Don't forget to leave your comments below
Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal's McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI's PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University's Executive Institute. He can be reached at firstname.lastname@example.org.