Mark Mullaly is president of Interthink Consulting Incorporated, an organizational development and change firm specializing in the creation of effective organizational project management solutions. Since 1990, it has worked with companies throughout North America to develop, enhance and implement effective project management tools, processes, structures and capabilities. Mark was most recently co-lead investigator of the Value of Project Management research project sponsored by PMI. You can read more of his writing at markmullaly.com.
Project management skills will play a decisive role in the evolution of government. Part of the equation lies in political will to provide the funds necessary to replace decaying infrastructure and improve access to services. As project managers, what can we do to deliver better projects for the public? Using agile is part of the answer.
As organizations increasingly face cybersecurity issues and make plans to stay a step ahead, there is a case for introducing information security (along with a proposed Security Review Board to stimulate the thought process) as part of project management processes.
In order to get additional scope, PMs need to go through an exception process for formal approval. You must prepare to present your case succinctly and answer the questions from the enterprise release board. Preparing answers to these 10 critical questions will help...
Project management software potentially offers a lot of value, a lot of which gets missed most of the time. Is this a problem of the software itself or how the software is being used? In last month’s article, I argued that some of best project managers can manage quite effectively on paper, and that arguably, many of us aren’t that much more efficient with software.
Assuming we have decent software, or even if we have software that has been thrust upon us as a result of corporate standards, the essential strategy for making any software work well is deciding how we want to work with it. In this article, I explore the considerations behind what we need to do to develop a good workflow for using software. What are the things we need to think about in using the software? What are the critical steps that actually enable us to define a useful software workflow? And why should we care?
To demystify the whole concept of “workflow” first: this is simply the conventions that we adopt that define how we actually want to use the software. The goals of having a workflow are two-fold: first, a good workflow should make us more efficient; secondly, a good workflow should make us more consistent. You may care more about the first than the second, but in reality you should care about both. The more consistent you are now, the easier it is to pick apart what you’ve done months after the fact, and therefore the more efficient you’ll be in the future. Consistency should lead to efficiency, as long as what we are doing is being done for the right reasons. Bureaucracy also can produce consistency, but we don’t always appreciate that as much.
The first thing we need to be clear about here is whether or not we’re building a personal or an organizational workflow. In other words, do I have discretion as a project manager for how I manage my projects and for how I use my project management software, or am I trying to co-exist with others in something that looks more like an enterprise toolset? If we’re building a personal workflow, we have a lot more discretion--and the motivation is more about establishing our own conventions for ease of use. If we have to play nicely with others, we are starting down the road toward an enterprise toolset (or it may already be there, and now we have to figure out what to do with it). The motivation in an enterprise context is about making sure that the tool is used in the same way, so that there is a level of trust about how the software has been setup and how it is being used. Both are important, but being very clear about the answer to this question is imperative from the outset.
Apart from the motivations behind developing a workflow being different, the other key differences between building a personal versus an organizational workflow are who we need to negotiate with. If it is a personal workflow, we mostly need to negotiate with ourselves and with our team members. This is still a negotiation; often we have to strike a balance between the clarity and detail that we want, and the effort that we want to put into maintaining it. I know that I could build more detailed schedules and resource plans, but the implications of doing so are more effort in the planning for me and in the tracking for my team. Unless there is a clear benefit for doing so that outweighs the costs of building and maintaining it, then I want to stay clearly on this side of the line separating me from the law of diminishing returns.
Negotiating an enterprise workflow is that much more complex. There is a wider array of projects to support, with very different sizes, scales and complexity to be managed. There are different stakeholders with different reporting expectations, and different project managers with different skill levels. There are varying politics, and evolving perceptions of what those politics mean. In all this variety, we need to find a way to consistently use the software in a way that works, that is productive and that allows us to develop and maintain a picture of project progress. If enterprise software is going to deliver value, and if it is going to be trusted in any way, then consistent approaches are essential. How we use the software is in fact one of the most important decisions that must be made in implementing enterprise project management software, and failure to do so is one of the single most influential factors in these implementations failing.
How we build a workflow is essentially similar whether the focus is personal or organizational (leaving the complexity of negotiations aside for the moment). The critical elements of the process are defining conventions for planning, and defining how tracking and reporting will be managed. To a certain extent, it is helpful to work through it in the reverse order: If we can define how we want to track and report (and the conventions around doing so), that will define the requirements of how planning must occur. Knowing both of these determines how the essential options of the software need to be set up.
Necessary questions when contemplating our tracking and reporting workflow are:
How often does progress need to be reported, and to how many stakeholders? Knowing the frequency of reporting, and how reporting needs to be managed, is a critical consideration.
To what level of detail does reporting need to be managed? Will you be reporting at the overall project or phase level, to project milestones or on an activity-by-activity basis?
How will activity progress be managed? Will team members report actual effort against each activity? Will they estimate the effort left to complete it? Will you use percentage complete? Or are you simply tracking when things start and stop?
Do you need to use more advanced control and reporting tools like earned value? What standards for earned-value reporting do you need to adhere to?
From this comes an understanding of our planning requirements for the software:
To what level of detail do we need to develop our schedules? Do they need to include activities? Deliverables? Milestones?
Does the activity plan need to adhere to an organizational methodology or process steps, or does each project have its own unique activities?
Will resources get allocated to project activities? Will this be based upon hourly estimates, or an overall approximation of work? Is there a common resource pool that will be utilized, or does each project operate in isolation?
Will the project schedule be managed and determined by dependencies? How will updates to the plan be managed, and what happens when actual progress means that the schedule isn’t progressing the way it is supposed to (a huge source of fear and anxiety for many project managers)?
Will activity durations be determined by resource effort? Or will they be defined and constrained for each activity?
The above questions start to define the considerations around how we use the tool. From there, we can begin to establish a proper workflow--the steps by which we will plan, and then by which tracking and reporting actually occurs. This becomes a process of defining what steps we follow each time we need to work with the software, whether during the planning or tracking and reporting stages of our project.
Some conventions around developing a workflow that have led to success in the past involve:
Planning the project step by step, just like you were taught in project management school. Build a work breakdown structure. Identify dependencies. Assign resources. Estimate effort. Allow effort to determine schedule. Estimate and finalize costs as a final step. Level resources. Finally, baseline the project. Do each step individually, for the whole project. That way, when you make a mistake or get an answer that stops working for you, you don’t have to go all the way back to the beginning to change things.
Make saving versions of your project a habit that borders on being obsessive compulsive. Whether you are planning or you are tracking, you will eventually come upon a problem that you hadn’t noticed before. Saving versions means that you can trace back your steps, week by week and change by change, to find out where the problem came from. Fail to do this and you will have earned yourself a stressful weekend with a lot of coffee (or worse!) figuring out how to fix it.
Once you have made a choice about how you are planning and tracking your project, stick to it. Don’t try to shift gears mid-project. If the organizational standards change around you, then argue long and hard about why your project should be grandfathered and allowed to complete the way it is already being managed. If you find a better way of doing things, make a note for the next time rather than making extensive changes this time around.
Be very clear with those who are working with you on the project about how you are managing the project, why you are managing it that way, what you need from them and how you will use the information. This is essential if you are going to get accurate and reliable information. If I know what’s needed, why it is needed and how it will be used, I’m likely to be a much more co-operative team member.
Developing an effective workflow is the most important step of using any software. At the beginning, it may feel awkward, formal and restrictive. Arguably, that’s the consistency talking. What will become quickly clear is the value that this consistency provides in knowing how you are using the software and in being able to explain it to others. Great software can be made useless by a bad workflow. Surprisingly, bad software can actually be made functional with a good workflow. It’s not the software so much as what you do with it.
Mark Mullaly is president of Interthink Consulting Incorporated, an organizational development and change firm specializing in the creation of effective organizational project management solutions. Since 1990, it has worked with companies throughout North America to develop, enhance and implement effective project management tools, processes, structures and capabilities. Mark was most recently co-lead investigator of the Value of Project Management research project sponsored by PMI.
Want more content like this?
Sign up below to access other content on ProjectManagement.com