In one of my previous posts, I suggested ways to maintain documentation. And as you know, documentation is very important -- it's the essence of knowledge transfer. The beauty of documentation is that it allows us to avoid the pains of reinventing a series of events that may only reside in a person's mind as a singular experience. It can also lead us to extract some aspect that may move our project from uncertainty and unknowns to more useful information.
So, once we have taken the precautions I mentioned in my previous post for generating clear and valid documentation, the question becomes: What project documentation should we always have and hold on to? I would suggest, at a minimum, the following:
The charter. It is the closest disclosure to everything the project should touch on. It includes a high-level look at the project: resource list, budget, timeline, assumptions, constraints, risks, other areas of impact and dependencies, a brief description and an immediate focus.
Budget background and expenditures. This information typically details the budget spending and directs you to possible future support, if any can be used again.
Sources. These include contacts and stakeholders; where information is stored; direct lines of contact; contacts who would be next in the succession; who and where to reach out to in case of additional needs; and where information stemmed from, and how it should be categorized and even prioritized.
A status report of risks and issues in their most recent form. These items show the progress that has or has not been made and is especially helpful in communicating to a new project manager (or yourself, if returning to a project) where to pick up. This status report can even help determine the project's resource needs.
Scope. This tells you what should have been the focus of the project. It also helps determine whether there needed to be an extension to this scope or if something different should be embarked upon, such as a total new project or maybe a revamping of the current scope.
Are there any types of documentation you find significant to have during a project and to hold on to after a project closes?
In my last post, I discussed my experience at the lab and insurance desk at a hospital. Now I'd like to share the remainder of the story and my analysis on the lessons learned from the hospital stay.
A nurse on my first evening in the hospital asked me to sign some papers. As I read the papers, there was a note that said I should not sign if the paperwork was not explained to my satisfaction. I looked at the nurse and said, "No one has explained anything to me. How can I sign?" The nurse looked at me and asked me to hold on for a moment. After some time, a doctor came, explained the process and situations that could arise during the operation. I asked some more questions that he answered, and I signed the papers.
Thursday morning, the operation was completed successfully, with follow-up visits by the doctor and nurse. On Friday, the process continued. A group of three senior staffers came in the room, introducing themselves as administrators, and asked if the air conditioning, food and other services were okay. In the evening, the doctor visited again and told me all was well and he would discharge me the following day. He said he would start the process in the morning and requested my patience as the billing and insurance-approval process might take many hours, even perhaps the whole day.
On Saturday morning, the administration staff visited again and asked if all was well. At noon, the staff took my signature on the bill and asked me to wait for approval. I sat around and inquired about the approval few times, but no luck. I finally got approval by 7 p.m. -- but by that point I had had dinner at the hospital and afterward moved to my house.
My experience at the lab and at the hospital were quite opposite. At the lab, the work at hand was minor, but it escalated. However, at the hospital the work at hand was greater and there were more opportunities for issues to arise, yet all went well. I think it was the hospital's well-defined process and disciplined execution that allowed for a smooth experience.
Takeaway 1: Words Have No Meaning, Only Action Works
At the lab, the manager was trying to defuse a situation by promising and explaining, but actions were missing, and therefore the matter became heated. At the hospital, when I was asked to sign papers without explanation, I raised the concern -- and the nurse and doctor both handled it well by doing what was expected without uttering a single word to the contrary.
Takeaway 2: Keep the Ego Under Control
The manager at the lab appeared to possess a big ego. First, he did not accept the problem; moreover, he defended his and his team's actions. Second, as he was also a doctor, he could have collected the blood himself but chose not to, perhaps because it wasn't in his job description. He missed the opportunity to win over customers and set an example for his staff.
Takeaway 3: Set Expectations
If the hospital staff had not set expectations that it would take two hours for approval on the estimated cost and a whole day for approval on the final bill, I would have waited impatiently and probably fought with the staff over the delays. But setting expectations in advance helped them control customer reactions and achieve satisfaction.
Takeaway 4: Have a Process, Maintain Discipline and Re-evaluate
The most interesting thing I found is that the administration staff visited my room twice and personally asked if all was going well. They were monitoring that discipline was being maintained and if anything in the process needed to be fixed. I think this was critical in ensuring foolproof processes and disciplined staff.
What's the top customer service lesson you've learned from an unlikely source?
Recently, my doctor advised me to go in for a minor surgery, so I had the opportunity to visit a clinical lab and stay at the hospital for three days -- an unlikely place to learn some customer service lessons.
Before the surgery, I had to undergo blood tests. There was only one attendant at the blood collection center and a long queue. A woman at the back began complaining about the queue until a nurse came out, took that woman to a room and drew her blood sample. This upset others in line and led to more complaining. The manager came out from his office and asked people to calm down. But after time passed with the queue remaining as long and the manager offering another assurance, people became agitated again. This time, the manager told some people they were unnecessarily raising their voices while he was trying his best. This continued until another staff member (possibly late to his shift) came in.
This experience made me think: Do mere assurances work all the time? Don't we need to apologize for unfair treatment and take action to correct the wrongdoing? Perhaps our egos do not allow us to do all this. So what does it take to control our ego?
After finally getting my test, I scheduled the surgery. The hospital suggested I come in beforehand to complete the formalities of cost estimation and approval from my insurance (a procedure in India for cashless treatment at a hospital).
When I arrived at the hospital's insurance counter, the attendant in charge took me to a room, asked me to fill out a form and told me that a few people are involved in the process, so it might take up to two hours. I filled out the form in a couple of minutes and waited for 30 minutes for a doctor to appear. He asked me a couple of questions, filled out the remaining form and gave it to the attendant. She asked me to wait for another half hour while she conducted some office formalities. Half an hour passed and I became restless. I approached the woman, and she promptly explained, "I said it would take around two hours. Hold on for some more time." After half an hour, she appeared, took my signature on a form and asked me to leave.
My experience at the insurance desk taught me a simple lesson. If I don't set expectations (as the attendant did), a customer is free to expect anything based on his or her own experience. For better customer service and satisfaction, it is important to set expectations at the beginning and then exceed those expectations.
In my next post, I'll discuss the lessons I learned from my hospital stay, and how those could be applied to project management. What customer service lessons have you learned when you least expected it, and how have you applied them in your projects?
Project trouble can hit from a blind spot, even though you tried as much as possible to prepare for issues. You did a risk analysis when you took the project on, and even tried to be ready to mitigate unknown issues.
As I advised in my previous post, do an assessment to determine the problem. Figure out what needs to be fixed, or if the situation is even fixable. If the project seems to have reached a point of no return, here are some tips on how to pull it out of trouble:
Finally, keep in mind that not all trouble devours all. Before panicking, calmly look to areas that will guide you to a solution. You may even find your project is more sound than it seems.
How do you confront trouble on your project?
First Steps Toward Recovery
Categories: Lessons Learned
In my previous post, I discussed points to help prevent problem projects. Here, I'll talk about what to do when you realize an existing project is headed for trouble.
Let me try to explain it like this: If you are driving a vehicle, what happens when you see a red light? You know that when you come to it, you will stop. After the light turns green, you will look both ways before proceeding. When our projects hit red lights, we as project managers must also stop and assess our environment.
As you look at the big picture, review your inputs, factors and the overall sanity of the project. Examine your risk register or issues log. Is the status of risks or issues showing something that was missed and needs to be addressed immediately? For example, something easily overlooked is when the schedule for applying security patches is on the same timeframe as the testing phase. This sort of impact can cause testing to grind to a halt, with the team unaware of the source of conflict. A review of the risks or issues log would have highlighted these events.
Another source to review is your budget plan. Have unplanned circumstances arisen, such as the need to produce more prototypes? Does the acquisition of resources require additional time? Is equipment becoming obsolete or in need of repair? Expenses such as these caution you to slow down and reevaluate your budget. Be aware that ultimately, you may need to secure a renewed budget approval.
Consider client relationships as well. Are your clients becoming unsatisfied and impatient, regardless of how well you're completing deliverables and meeting milestones? If so, you may need to allay fears or even compromise on a feature of your project. Perhaps that means reconfirming a budget forecast, or something as simple as picking up the phone and calling the client with an impromptu status report.
One last piece of advice: Take a look at lessons learned. It's very likely a previous project manager may have outlined specific pain points on similar problem projects. These will provide valuable insights that even the most technically experienced project manager can lean on. They're good for figuring out what to do in grey-area situations: when it was difficult to get management signoff on a needed budget increase; how a concern was handled when a client change request was denied; or how to garner support when team conflicts arose.
After you recognize there's trouble ahead, how else do you assess the size of the problem?