Anton's profileProject Management and C...BlogLists Tools Help

Blog


    Growing a client relationship

    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.

     

    Operant Conditioning

    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.

     

    Good Insights On Managing Knowledge Workers

    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: , , , Litigation Support 

    Gathering requirements for small projects

    In my new role as a Director of Project Management at Legal Science, I have the responsibility of setting up our project management practices and helping our customers manage their litigation support projects.  A few pain points that I hear often from our customers are the ambiguity of requirements, the short duration of projects, and the fast pace of litigation support projects.  In fact, many have given up on requirements gathering and accept the fact that 50% of their projects will be over budget, low quality, or over schedule.

    However, all is not lost.  Proper requirements gathering can set a project in the right course from the very beginning.  Unfortunately, requirements gathering is a tricky process fraught with red herrings.  Sometimes you interview a stakeholder and write down exactly what is said only to find out that is not what they intended.

    The trick here is to find out what the client "intends to do with the product" not how they think the project should be done.  This is sometimes called the "business requirements."  Many vendors in  the litigation support space jump right into checklists with options for stapling papers this way or that way.  But in doing so, they miss the more important point of what the customer intends to do with the end result of the project.  They are trying to find out the "technical requirements" before they even understand why they are undertaking a project.

    Here is my list of best practices for gathering requirements for small projects:

    • Use the following techniques to solicit requirements as fully as possible:
      • Interviews - Solicit requirements from project stakeholders.  However, take into account each person's bias and background.  Use context-free questions, ones that do not favor one answer over another, to avoid bias
      • Document Analysis - Any documentation generated at the beginning of a project is a treasure trove for requirements gathering.  These will give you a good foundation on which to build upon
      • Brainstorming - Sometimes the stakeholder is not exactly sure what the requirements should be.  In this case, a brainstorming session will help flesh out ideas and potential uses of the end product
    • Establish a process for evaluating and controlling changes to requirements.  This is not to discourage changes, but to fully understand the impact of a change and notify all of the appropriate parties of changes in scope
    • Prioritize!  Some requirements are more important than others, if this is so, state it explicitly.  Nothing is worse than getting a project late because a minor requirement was slowing down important work
    • Consider an incremental approach when requirements are volatile.  You don't have to do the entire project at once
    • Distribute requirements to all parties of the project.  This way everyone knows what needs to be done and why.  This is especially important so that the stakeholders see and verify your understanding of the project
    • Check your final deliverables against the requirements

    If you have any horror stories or best practices regarding requirements gathering, leave a comment!

    Good follow up post by Harrison Flakker at Select Notes From Caselawg entitled "How to gather requirements from an attorney walking backwards"