In my industry, workflow is considered by many as a holy grail.  Most leaders of litigation support departments feel that they can control risks, issues, schedules, and quality through one comprehensive workflow or even a checklist.  It is tempting to think that a machine could orchestrate a project to such a degree of success that the humans involved cannot make errors.

Unfortunately, there is no perfect workflow in our industry.  Not a single litigation support manager I have spoken to feels that they have their hands around the problem.  And so, we look at vendor after vendor peddling their software with a state-of-the art workflow system built in.

So, why do these system's fail to achieve their promised goals?  Here is my list of "gotchas" about attempting to automate your project management functions via workflow:

• Poor planning - insufficient involvement by everyone involved with the system (IT, front-line employees, and management) during the early evaluation and planning stages of the implementation can lead to ballooning budgets and quirky systems forcing the employees to use workarounds and introduce all new and unknown risk into the process.
• Poor understanding of the limitations of workflow - it may handle human-to-human task management but when you add human-to-system and system-to-system interactions, event management/correlation, performance monitoring, change management, and process rules many systems just fall apart.
• Poor change management - sometimes the implementation of the workflow takes several months to complete.  Even with perfect planning at the beginning of an implementation, sometimes changes in the business outpace workflow development.  Many implementers fail to keep up with the pace business causing the delivered workflow to be out of date and unsuitable.
• No implementation with LOB applications - users touch many systems during a business process.  Many of these interactions are not documented anywhere.  A good workflow system needs to take into account integration with billing systems, case management systems, etc.
• Automating chaos - if your process is not clearly understood, defined, and optimized you will be automating chaos via workflow.  The result of this can only be "automated chaos."
• Forgetting the people -  sometimes it is important to understand that it is not all about nuts and bolts.  It may not be about the lack of Change Management or the way integration is done with LOB systems.  It’s about PEOPLE.  Involve the users, educate the users and get buy-in up-front, let the users champion the project direction, talk to the front-line employees and narrow the gap between IT techniques and the Business requirements.

Keep these things in mind if you insist on purchasing a system that attempts to automate your project management.  However, I recommend that litigation support managers look spend some time and optimize their people and process before they attempt to automate things.  Sometimes, the right people are all it takes.

Technorati Tags: project management, workflow, litigation support

Craig Brown of Better Projects wrote an excellent post highlighting the reasons why a client might prefer to work with certain people even though other equally qualified people are available.

"Patients will [...] cross the city to visit their preferred GP [rather than visiting the nearest available doctor]. Patients are not in a good position to assess the quality of medical advice they receive, so what makes them care enough about a doctor to make such efforts? The answer is the "bedside manner" which in the context of this [project management / consulting] is their empathy."

Project managers and consultants need to empathize with their client, their employees, and other stakeholders.  Through empathy, one can truly understand the issues that the other party is dealing with and respond with sincerity.

Once, I was involved in a project where the client services manager had to relay a possible budget overrun to the client.  Unfortunately, the client had been under the impression that the supplier would absorb any cost overruns.  The first course of action that the client services manager took is to explain in detail to the customer how high the quality of our services has been and pointed out relevant passages in the contract to correct the client's perception.  However, the client soured on the relationship feeling that he was being cheated.  When the issue was escalated, the executive from our company listened very carefully to the client's pain points and empathized with him.  This led directly to an improvement of the client relationship and contributed to a successful negotiation and follow-on work.

Do you have any stories where empathy or lack thereof led to a change in the client relationship?  If so, leave a comment.

 

Raven at Raven's Brain has posted a great quote regarding Good Insights On Managing Knowledge Workers that I think applies even more to the litigation support industry.  Litigation support is part of the information and support economy and most of the people in this industry are knowledge workers.  Knowledge workers are people who add value through their intellect rather than physical attributes.  Because knowledge workers use intellect rather than brawn, old techniques of managing users by just assigning tasks and jobs has become harder.  Workers are no longer doing one task at one workstation.  They have valuable skills that should be fostered and used in the best possible combination. 

"A good manager doesn't tell people what to do or how to accomplish their tasks, but removes roadblocks and makes the way clear [for employees to be] more productive.  [Another] important role that managers have is to identify and grow talent.  Unfortunately, many managers don't place enough emphasis on helping the individuals within their teams grow and improve their capabilities.  Ultimately, a manager [ONLY] succeeds when the people who reported to him grow into new capabilities and roles." -- Jeffrey Phillips at Think Faster

Managers who do not foster each knowledge worker's talents or hold on to the outdated "workers as resources" mantra will have a hard time keeping employees motivated in this industry.  Empowering an employee is the only way to harness the talent that the company has and is a very challenging feat.  That is something that I want to explore further in future posts.

How do you empower your employees?

Read the article on the Think Faster blog entitled "What's a manager to do?"
Read the article on Raven's Brain blog entitled "Good Insights On Managing Knowledge Workers"

Tags: Knowledge Workers, IT Management, Management, Litigation Support 

As a consultant, I visit many organizations and speak to them about project management. A large majority of managers who deal with small initiatives complain that project management methodologies are overkill for their project/organization. Furthermore, some use this logic to justify their lack of following any sort of project management processes or techniques. It is with these Project Managers in mind that I read Tom L. Barnett's A Small-Project Playbook article on ComputerWorld. An article that promised to find the solution for the manager of small projects.

In the article, Tom proposes that in such circumstances a Project Manager can use his Playbook "tool" to manage the project. The "tool," however, is nothing more than a chart consisting of "eight columns: Task Name, Description, Due Date, Owner, Issues, Deliverables, To, and Waiting On." Tom says this allows him to replace the WBS, meeting agendas, resource assignment matrix, and status reports.

However, I view this as a dangerous proposition when speaking to clients that are already weary of project management. The playbook is just a tool that will be rather useless in the hands of a person that does not already know the project management concepts that are used to populate it. Project management is a set of processes, not tools. Furthermore, it serves as a poor introduction to project management techniques for the beginner. Rather than learning proper project management and using critical thought to apply the appropriate techniques, beginners will learn bad habits right from the start. The tool does not even encourage a small project manager to split their activities into initiation, planning, execution, and closing. It transforms a project manager into a task master.

Rather than taking the less-than-ideal approach, beginners should focus on light-weight management methodologies like SCRUM, an agile methodology focused on small, cross-functional teams. From this, they will learn the benefits of setting up and following processes without burdening the organization with heavy frameworks. New project managers need to understand that success is more dependent on critical thinking and process than tools and technology. The bottom line is: neither the playbook nor Microsoft Project will make one a project manager.

For more information about Agile methodologies, see Raven's article Good List of Agile Program/Project Management Resources.

In his article "Expectations and Violations," Paul Glen discusses the human side of project failure. We consultants are often called in to a company as a last resort to save a failing project. Typically, this happens after a project has missed deadlines. The company realizes that the imminent failure of the project is not due to poor schedule or cost management but to human and business relationships.


I completely agree with Paul on this issue. It is nearly impossible to avoid poor project performance without considering human issues and expectations. Functional managers have dealt with human issues far longer than pure project managers. However, we must do our best to manager people as much as cost, schedule, and scope.

Do you have examples of projects that have failed because of human issues? Leave a comment.

If you already have some degree of Project Management practices at your company, why would you hire a consultant to review those practices?  As a consultant, I get asked this question all the time.  Believe it or not, the answer is very simple and compelling.  Since it comes up frequently, I have decided to make a top 5 list on the blog.

1. A consultant provides objective feedback - Since consultants are not part of company politics they lend credibility to arguments impartially
2. A consultant provides a fresh set of eyes - Consultants will offer a different perspective on your ideas making them more comprehensive
3. A consultant can be a source of ideas - The very nature of consulting exposes people to many ideas and implementations that they can offer your business
4. A consultant can be your sounding board - Consultants can validate your ideas and give you the confidence to pursue them
5. A consultant can keep you accountable - Having the consultant review, probe, and strengthen your ideas helps keep you focused on meeting your company objectives

Have you had experiences with consultants that would add to this list?  If so, leave a comment.

When should you kill a project?

This is a topic that is rarely discussed in the industry because of the stigma of failure.  No one wants to look bad in front of his or her customer.  So they crash (add resources), fast track (do tasks in parallel), and generally throw good money after bad until a project completes or becomes impossible to complete.  This problem is typically magnified in companies where a project manager's reward is based on successful project completion.  However, as project managers it is our duty to monitor the health of a project and if the time comes where it makes sense to kill the project we should advise our customers honestly.  How do you know when the project really needs to be killed?  The answer is very simple.  There are three reasons to kill a project:

• The company strategic plan has changed and the project no longer aligns with business goals
• The cost of completing the project is higher than the expected return on investment
• The project is meant to exploit a window of opportunity in the market but it cannot make the schedule

If either of these conditions are true, kill the project.  I will go one step further and say this: kill the project as early as possible.  All good poker players know that it is better to fold early and only bet big when success is assured.  I have been on several projects where management did not kill troubled projects in a timely manner only to find that they spent more than planned and did not get the result they were hoping for in the end.

In my experience, the top two reasons that projects are not killed when it makes the most sense are:

• Fear of failure
• Project managers who value completed projects over fiscal responsibility

The first reason is a false belief that one looks good only when they are finishing projects.  This is the leading cause of reckless project management techniques to make the deadline no matter what.  However, from a business point of view, a project manager looks much better at review time when they demonstrate a fiscal responsibility to management.  Five killed projects for minimal losses and one successful one that makes a huge return is more beneficial to a client than pouring money into one troubled project that will ultimately not achieve its goals.

The second reason that projects are not killed timely is just plain irresponsible project management.  This happens when a project manager worries more about looking good in front of their boss than the interests of the company as a whole.  These project managers will sometimes whitewash information, hide facts, or generally make a project look healthier than it really is.  In the end, these projects inevitably fail to achieve their objectives.  Unfortunately, even if the project is ultimately unsuccessful these project managers succeed in convincing or deceiving management into investing more money than is probably prudent.

Do you have stories of projects that should have been killed but were not?  Leave a comment for the benefit of all the other project managers out there.

It is inevitable. At some point in time, either you or your employee will miss a deadline. Sometimes that deadline will affect customer deliverables and make you and your organization look bad in front of a client. This is the subject that caused Trizle to come up with a shortsighted initiative he calls "No Deadline Left Behind."  The premise behind this idea is to punish employees monetarily for missing deadlines. On the surface, this seems like a reasonable, maybe even sensible, policy. After all, an employee should be incentivized to meet contractual obligations. However, after some analysis this approach, though intuitive, is the wrong one.

It seems that Trizle means to punish employees for the failures of the project manager. Most deadlines are missed because of poor estimation, risk management, and progress tracking. Unless those areas of Trizle's process are fixed, he will just shift the blame and punishment of the problem on the poor employee who has little control over the actual deadline itself. The result of such a policy will be inflated timeliness (as employees seek to minimize their risk), higher costs (employees will charge more for some work to offset loses in other work), and no improvement in the ability of an employee to consistently meet a deadline. Furthermore, employees will reach a point where the risk of losing their income becomes so high that employment at Trizle's company will no longer be a viable option for them. As an example, Rob Garrett's response to this article demonstrates a typical employee's reaction to such a policy.

"No Deadline Left Unmanaged"

Instead of the "No Deadline Left Behind" as Trizle suggests, I have come up with a realistic strategy. The strategy starts in the planning phase of a project. Here, the typical pitfall is poor estimating. While it is common to use a team member's expertise to judge the effort required for a task, this path is dangerous and should be only used as a last resort. Instead, use techniques like parametric models, commercial databases, or weighted averages to get estimates that are more accurate.

Parametric models are mathematical formulas used to estimate the total duration of a task based on variables. For example, "it takes me 2 minutes to lay 1 tile, the tile is 1 foot by 1 foot, and the room is 100 sq. feet. Therefore, it should take me approximately 200 minutes to lay enough tiles to fill the room."

Note: Problems that are more complex require models that are more complex. Additionally, pay close attention to how well the model scales (it may take 2 minutes to lay 1 tile in a small room, but increasing the room size may not increase the total time in a direct proportion)

Weighted averages, such as used in the PERT technique, allow a manager to consider an optimistic estimate, the average estimate, and the pessimistic estimate to come up with a figure that is realistic.  The PERT formula for this is:

T_E = (O + 4M + P) ÷ 6

Where O is the optimistic estimate, M is the average estimate, P is the pessimistic estimate, and T_E is Expected Time. Performing a standard deviation analysis can show the manager how confident they can be in the estimate.

After these techniques are used to come up with estimates that are realistic, it is paramount to control the scope of the project to prevent missed deadlines due to scope creep.

The second phase of the strategy comes into play during risk management. Each employee should be positively encouraged and incentivized to report project risks to the PM (or risk management officer) immediately. The PM can then form a risk response plan to accept, mitigate, or transfer the risk of a missed deadline. Accepting a risk means realizing that a risk exists but doing nothing to prevent it. Mitigating the risk of a missed deadline could involve adding resources (crunching), re-negotiating the deadline, or doing tasks in parallel (fast tracking). Transferring the risk could involve obtaining an insurance policy (this moves the risk from you to your insurance provider).

Note: Punishing employees for missing deadlines is a form of transferring risk because they end up paying for your mistakes.

The third phase of the strategy is for the PM to be intricately involved in the monitoring and controlling activities during the execution phase of a project. A manager that does not track progress until deadlines are missed should shift their focus onto actively managing their people. Tools like EVM (Earned Value Management) are essential in effectively tracking project status. EVM allows the PM to "objectively track physical accomplishment of work [by] combining measurements of technical performance (i.e., accomplishment of planned work), schedule performance (i.e., behind/ahead of schedule), and cost performance (i.e., under/over budget) within a single integrated methodology."

In my opinion, these three improvements in the project management area will drive improved management of resources, risks, and schedule in a much more efficient manner than transferring risk to your own employees.