Project Management methodologies, classes, and books are adequate at explaining the mechanics of running projects and the tools used to do so. Understanding these mechanics is essential, but it is experience that distinguishes successful Project Managers. More specifically, it is the sum of all of the negative experiences that Project Managers have in their careers that teaches them what not to do. As Vernon Law explains, "Experience is a hard teacher because she gives the test first, the lesson afterwards."
In my many years of Project Management experience, I have come across several areas that consistently cause projects to experience difficulties. I call these the "uglies" of projects since these are the things that make projects turn ugly. These are also usually the things that, once recognized, are hard to fix easily. This article will discuss the ten project "uglies" and propose some resolutions. There are definitely other "uglies" out there, but these ten are the ones that seem to be the most common and have the biggest impact based on my experience.
THE TEN "UGLIES"
Below are the ten "uglies" with a description of each and some symptoms that indicate that these "uglies" may be happening.
1. Lack of Maintained Documentation
Oftentimes when projects are in a crunch, the first thing that gets eliminated is documentation. Sometimes documentation isn't created even when projects do have the time. When documentation is created properly, as projects continue to progress it is a rarity to see the documentation maintained.
Symptoms:
* Requirement documents that don't match what was produced
* Technical documents that can't be used to maintain the technology because they are outdated
* No documentation on what decisions were made and why they were made
* No audit trail of changes made
This is a problem since documentation provides the stewardship of the project. By this I mean that future projects and the people maintaining the project once it has been completed need the documentation to understand what was created, why it was created, and how it was created. Otherwise, they wind up falling into the same traps that happened before - in this case "he who ignores history in documentation is doomed to repeat it."
2. The Pile Phenomenon
"What is that under the rug?" is a question often asked towards the end of a project. The mainstream work always gets the primary focus on a project but it is those tangential things that get forgotten or pushed off until 'later', at which point there are several piles (swept under the rug) that need to be handled. I call this the "pile phenomenon" because team members think of it as a phenomenon that all this "extra" work has suddenly appeared at the end.
Symptoms:
* Any work that gets identified as "we will do this later" but is not on a plan somewhere
* Growing logs (issues, defects, etc.)
* Documentation assumed to be done at the end
There is no "later" accounted for in most project plans and therefore these items either get dropped or there is a mad rush at the end to finish the work.
3. No "Quality at The Source"
Project team members don't always take on the mantra of "quality at the source." There is sometimes a mentality that 'someone else will find the mistakes' rather than a mentality of ownership of quality. A Project Manager doesn't always have the ability to review all work, so they must rely on their team members. Therefore, the team member must have the onus to ensure that whatever they put their name on represents their best work.
Symptoms:
* Handing off work with errors before reviewing it
* Developing code without testing it
* People not caring about the presentation of their work
There are several studies that show that quality issues not found at the source have an exponential cost when found later in the project.
4. Wrong People on the Job
Project roles require the right match of skills and responsibilities. Sometimes a person's skillset does not fit well with the role that they have been given. I also find that work ethic is just as important as skills.
Symptoms:
* Team members being shown the same things repeatedly
* Consistent missing of dates
* Consistent poor quality
As Project Managers, all we have are our resources. Not having the right fit for team members will result in working harder than necessary and impacts everyone else on the team who has to pick up the slack. There's also a motivational issue here: when someone is in the wrong role, they may not feel challenged or feel that they are working to their potential. This has the impact of that person not giving their best effort, not embodying a solid work ethic when they normally would, feeling under-utilized, etc.
5. Not Involve the Right People
The people who know how to make the project successful are the team members working on the project. Not involving the right team members at the right time can set the project up for failure before it begins
Symptoms:
* Having to make changes to work already completed
* Constant scope changes from the customer
* Lack of team buy-in to estimates
* Lack of ownership of decisions
Not involving the right people up-front in a project always results in changes to work. Not involving team members in decisions and estimates causes them to feel like they have no control over their work or the outcomes of the project.
6. Not Having Proper Sponsorship
Projects need internal and customer executive sponsorship to be successful. Sponsors act as tie-breakers and eliminate organizational politics/roadblocks that are holding up the project.
Symptoms:
* Inadequate support from different areas of the organization and from customer stakeholders.
* Issues taking very long before being resolved
* Decisions not being made efficiently
Not having proper sponsorship can result in projects "spinning their wheels." Also, when a change effort is involved, not having proper sponsorship can keep impacted employees from buying in to a project (i.e., not cascading the messages from the top down to the "masses")
7. No Rigor Around Process
Almost every company uses a methodology for implementing projects. The success of these methodologies depends on the amount of rigor used on the project. Often, processes are not adhered to and projects run awry.
Symptoms:
* Incomplete/non-existent deliverables
* Inconsistencies within the project
* Lack of understanding of the project's big picture
* Lack of repeatable processes ("re-invent the wheel" unnecessarily)
Processes are only as valuable as the rigidity placed on them. In some companies, there are too many project management methodologies used. Some are necessary due to the varying nature of work, but basic project management practices and principles (and even tools - i.e., using Project vs. Excel) could easily be standardized, but are not.
8. No Community Plan
Project Managers spend a significant amount of time on planning, estimating, and scheduling activities. If these results are not shared with team members, then they do not know what they are working towards and cannot manage their own schedules. This includes the communication of goals and items that are big picture for the team.
Symptoms:
* Lack of knowledge about what is due and when it is due
* Missed dates
* Lack of ownership of deliverables
* Deliverables get forgotten
Not having a community plan will result in not having an informed community. Having a shared plan and goals helps to build cohesiveness and a greater understanding of how the work of each individual fits in overall
9. Not Plan for Rework
Estimation techniques often focus on the time that it takes to create units of work. What usually gets left out is the time spent on rework. By this I mean work that was done incorrectly and needs to be revisited as opposed to scope management. When rework is required it either takes the place of other work which now comes in late or is pushed off until later (see "ugly" #2).
Symptoms:
* Missed dates
* Poor quality
Never assume that anything is done right the first time.
10. Dates are Just Numbers (No Sense of Urgency)
Schedule is a major driver of project success. I am amazed at the number of people who think of dates as 'suggestions' rather than deadlines. Because of interdependencies on projects, a missed date early on could ripple through the schedule for the remainder of the project.
Symptoms:
* Consistently missed dates
* Items left open for long periods of time
* Incomplete/non-existent deliverables
* Lack of a sense of urgency on the project team
Without structure around the management of dates, success requires a lot more effort. One other issue here is that of communication - these dates need to be communicated clearly and people must agree that this is their target. Also, they must understand what is on the critical path, and what has slack, so if they slip on a critical path item, they know there is an impact to the project, or to another project within the same program.
POSSIBLE REMEDIES
1. Proactive Management
Proactive management means spending the appropriate amount of time up-front to minimize the number of 'fires' that need to get put out later. Proactive management includes the following actions:
* Creation of a detailed plan
* Always looking at the plan to see what is coming up and preparing for it
* Constant replanning as information becomes more available
* Understanding what is going on with the project. I see so many PMs in the "ivory tower" mode where they find out about things about THEIR project for the first time on a status report. By this time, as much as a week has gone by before the PM is aware of issues.
There will always be unexpected issues that arise, but proactive management can help to mitigate those things that are controllable. This can be treated as an investment of time, in that you will spend far more time (and money) reacting to problems than you will focusing on ensuring that the process be followed properly. This is difficult for some Project Managers because it requires the ability to always look ahead of the current state of the project rather than just focusing on the problem of the day. A key element of proactive management is having the ability to make decisions efficiently.
2. "Do It While You Do It"
Now that you are not reacting to fires, you can focus the team on maintaining their work as they go. This means staying focused on all aspects of the current work and thinking of implications. Characteristics of this include:
* Documenting as work is being done and not at the end. I am sure that this will get the knee-jerk "we don't have time" reaction but I really believe (and have proved) that documenting as you go takes far less time than doing it at the end.
* Thinking of implications as things change on the project. For example, if a document changes, the owner of that document should think about any other deliverables that may be impacted by the change and communicate it to the appropriate person.
* Check all work before passing it on to others
* Use the process/plan as a guideline for what work has to be done. I have heard this referred to as "living the plan."
The result of this technique will be an even distribution of work across the project and minimal spikes at the end. Rather than the notorious "death march" the worst case could be considered an "steady marathon."
3. Empower The Team
PMs must realize that project structures resemble an inverse pyramid where the Project Manager works FOR the team. It is the team members who do the work on the project, so the PM's primary role is to support them and address obstacles that may keep them from completing their work. This includes:
* Involving team members in project planning so they can't say that they were just given a deadline by management
* Ask the team members how things are doing and then act on their concerns. Asking for feedback and then doing nothing about it is worse than not asking at all because it suggests an expectation that concerns will be addressed
* Celebrate the successes of the team with the team members
* Be honest with the team members
Empowering the team will enable the PM to share information with the team members and will also enable the team members to feel like they have control over their own work. The result is that each team member becomes accountable for the project.
CONCLUSION
Focusing on proactive management, keeping up with work, and empowering your teams are keys to running a successful project. Nothing in this paper hasn't been written of or spoken of hundreds of time before. Nothing on this paper should sound new to a Project Manager. And yet, we keep seeing the "uglies" over and over again. That leads me to a conclusion that it is the application of these concepts that is the challenge. I find that after I read a good paper or attend a Management course, I have great enthusiasm to try out the new techniques but at the first signs of trouble I revert back to my comfort zone. Therefore, I would propose that there is a fourth remedy for the uglies - being conscious. This is nothing more than being aware of what is going on and how you are managing your project.
I come in to work every morning a little earlier than the rest of the team so I can have my quiet time and think about what works needs to be done (not just for that day but in the upcoming days). I also give myself reminders that trigger my "step back and think" mode. An excellent series that goes into this technique are the "Emotional Intelligence" books by Daniel Goleman.
There will always be "uglies" on your projects, but if you are conscious of them then you can identify them when they are happening and you may be able to prevent them from throwing your projects into chaos. Best of luck.
- Kerry R. Wills
No comments:
Post a Comment