Project Management and Consulting

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.

 

In my previous article, Good Insights On Managing Knowledge Workers, I concluded that "Empowering an employee is the only way to harness the talent that the company has and is a very challenging feat."  However, this is only the first step in the process.  Since posting that entry, I have been researching the psychology of motivation.

In psychology, the process of learning new behaviors or responses as a result of their consequences is called conditioning.  I believe that the average employee has been conditioned to follow orders, to keep quiet, and do the minimum amount of work.  Through their experiences at previous jobs or projects, employees have picked up an attitude that prevents them from accepting empowerment even if given full authority to make their own decisions.

The first job of a project manager in this situation is to condition the employee to respond positively to empowerment.  The PM has to encourage positive behaviors and diminish the negative ones.  There are four commonly accepted methods of reinforcement to do just that:

 

• Positive Reinforcement. Something positive provided after a response in order to increase the probability of that response occurring in the future. For example, recognizing that an employee has stayed late last night and saying "thank you."  The most common types of positive reinforcement or praise and rewards, and most of us have experienced this as both the giver and receiver.
• Negative Reinforcement. Think of negative reinforcement as taking something negative away in order to increase a response. For example, nagging the employee to fill out his weekly timesheet on time until they start doing it automatically. The elimination of this negative stimulus is reinforcing and will likely increase the chances that the employee will fill out their timesheet next week.
• Punishment. Punishment refers to adding something aversive in order to decrease a behavior. The most common example of this is disciplining an employee for being late. The reason we do this is because the employee begins to associate being punished with the negative behavior. The punishment is not liked and therefore to avoid it, he or she will stop behaving in that manner.
• Extinction. When you remove something in order to decrease a behavior, this is called extinction. You are taking something away so that a response is decreased.  An example of this is removing an employees internet access to discourage them from playing games during work time.

Being aware of how our actions reinforce behaviors is something that project managers need to keep in mind.  Have you ever let an employee slide with a poor excuse in a status meeting?  If you have, you just used positive reinforcement with an undesired behavior.

 

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.

According to a study by Dr. David P. Norton, of the Palladium Group and Cognos Corporation, nearly 90% of companies are having trouble executing their corporate strategy. However, the ten percent of companies that do manage to execute their strategies achieve dramatic benefits. If your department or company has trouble in this arena, I recommend that you do a quick self-evaluation in the following four areas:

• Executive leadership - Do executives do everything in their power to enable your group to achieve your objective?
• Organizational structure - Does the organizational structure prevent your group from achieving your objective?
• Process paralysis - Do your existing processes prevent you from being able to achieve your objective?
• Bad goals - Are your goals achievable?

It is worth noting that bad goals are often cited as a reason for failure throughout industry. Fortunately, bad goals are simple to correct using techniques such as SMART goals. There are five guidelines for making a goal SMART:

• Specific - The goal should be exact regarding what the team hopes to accomplish.
• Measurable - When a goal is measurable, the team knows exactly when the goal has been achieved and what has been achieved.
• Agreed upon - Everyone involved in the process in question, especially all Six Sigma team members, must agree to the goal and agree that its successful completion is important. At some point, all team members and project stakeholders will be asked to contribute their time and resources to the project. Agreement commits everyone to achieving the same goal.
• Realistic - Whether a goal is realistic depends on the resources and needs of the organization. Make sure the goal is neither too ambitious nor too trivial. Make it just right.
• Time frame - Like all the elements of the project goal, the time frame should be realistic. The time frame should be achievable yet limited enough to make the goal valuable to the company.

By their well-defined nature, SMART goals help keep an organization or project team focused and dedicated to a common vision.

References:
Read the full study by Dr. David P. Norton: Making Strategy Execution A Sustainable Competitive Advantage
Read the article on the Be Excellent™ blog entitled "Making Strategy Execution A Sustainable Competitive Advantage"
Read the article on the Anticlue blog entitled "Six Sigma Creating SMART Project Goals"
Read an article on SMART goals from Raven's blog entitled "10 Tips for Setting SMART Goals / Objectives"

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.

This is an exciting time to be in the Project Management and IT industries, as both are rapidly maturing and adhering to common processes and best practices.  However, this is a daunting time to become a project manager or IT consultant.  Lots of frameworks, best practices, and methodologies are competing for your attention.  Some are good, some are bad, but most are "good in certain situations."  All of these new ideas remind me of a profound saying that I learned in college:

"In theory, theory and practice are the same.  In practice, they are not."

An example of this recently came to mind for me.  The IT Infrastructure Library (ITIL) framework is completely based around the idea of a Configuration Management Database (CMDB).  In theory, the CMDB combines information about all aspects of an information system, the business areas it supports, and service levels.  However, in practice no such database system exists.

If you are considering an ITIL implementation, please read the IT skeptic's blog.