Seven Habits of Highly Destructive Project Managers
You have all heard about the book Seven Habits of Highly Effective People. Here is a similar list of seven habits - only these are for highly destructive project managers. (In other words, you don't want to do these things.)
1. Motivate by intimidation. Since project team members rarely report functionally to the project manager, some project managers try to "motivate" team members by instilling fear. This could be by shouting, threatening to remove them, humiliating them at team meetings, etc.
2. Not knowing your team. The personal lives of team members impacts their work behavior as well. An effective project manager knows enough about his team members that he is able to understand what motivates them. This does not mean you have to pry into every personal details. However, show some interest in the team members as human beings to build a more effective work environment.
3. Not being open to ideas. Some project managers believe that there is just one way to do things right, and that one way is their way. Not being open to team suggestions and ideas stifles their creativity. Such a closed attitude prevents new and better methods from being implemented.
4. Negative expectations. Many project managers are convinced that employees are untrustworthy, sneaky and lazy. This causes them to constantly monitor team members and treat them like children. In a situation where expectations leads to reality, this type of project management behavior can lead the team members to actually become poor performers.
5. Not communicating performance expectations. Many team members are shocked to learn about project manager perceptions and expectations late or at the end of the project. Ineffective project managers withhold a lot of important information from team members - including their performance expectations. They then provide negative input to the functional managers for performance feedback, which is terribly de-motivating to the team members affected.
6. Viewing themselves as the only decision makers. Ineffective project managers tend to believe that they alone make all the decisions. They fail to realize that project managers are as prone to making errors as anyone else, and people that admit their errors stand a chance of thrive and grow.
7. Creating a negative work environment. Project managers help shape the organization culture. This helps determine whether team members enjoy work or dread it. An organization of poor project management leads to poor project execution, which leads to all kinds of negative characteristics for the entire work environment.
As a project manager, look at the list above. If you are doing the opposite of these traits you are probably doing well. On the other hand if you have one or more of these habits you should think seriously about changes.
Click here to listen to our Best PM Podcast episode for today: http://bit.ly/PMPodcast355
20,036 project managers have listened to it so far!
It’s time. It’s time for strategic project management to be directly represented at the executive round table, in board meetings, and in the ‘C’-suite. It’s time for singular ownership and accountability for organizational strategic planning and execution. It’s time for dedicated focus on organizational resource planning, allocation and utilization. It’s time for focused attention regarding return on investment, earned value on execution, appropriate risk management and post-execution benefit capture. And finally, it’s time for single-sourced, unambiguous communication regarding strategic balance, allocation of resources and prioritization of the directives that constitute the portfolio of investments that the organization makes on its own behalf.
What you have just read is the opening paragraph of the article It’s Time for Project Leadership To Have A Seat At The Executive Table written by Paul Williams (http://www.thinkforachange.com/aboutpaul). In it, he emphatically argues that project management is just as important as any of the other more traditional business departments such as marketing, finance or operations.
In our interview, Paul and I review his general argument why project leadership needs a seat at the executive table, what the roles and responsibilities of our representative are, what skills he or she needs, and what you can do as part of your career planning to become that very person.
Estimating Productive Hours per Day
Estimating is one of the most critical aspects of project management. A project management methodology will help you develop estimates using a common process and techniques. There are three major elements of project estimating - effort, duration and cost. You must start with an estimate of effort hours. Duration can then be calculated by looking at the effort and the number of resources that you can apply. For example, one person may be able to complete an 80-hour activity in two weeks. Two full-time resources could complete the work in one week.
"Productive" Hours Per Day
Another factor in converting effort hours to duration is to define how many productive hours of work you can expect in a typical workday. For example, if you have an activity that you estimate will take forty effort hours; it is unlikely that it can be completed in five eight-hour calendar days. No one is 100% productive. You need a "reality factor" to convert the estimated effort hours to estimated duration.
Employee Productive Hours
A productivity factor takes into account the amount of time a typical person will actually work in a day. This productivity factor assumes things like social interaction with colleagues, going to the bathroom and traveling to meetings. It also factors in the time people need to ramp up in the morning, as well as people that start to fade in the late afternoon. A generally accepted rule-of-thumb for average productive hours per day is 6.5, based on an eight-hour day. This is an 80% productivity factor.
Contractor Productive Hours
When you have contract resources, you should also take a productivity factor into account. Even though these resources are contractors, they will still experience many of the factors that lead to a less than 100% productivity factor. For instance, they are still going to socialize a little and they still need to go to the bathroom. A good rule of thumb for a contract resource is 7 to 7.25 productive hours per day. This factor recognizes that the contract resources are not robots and they will not be 100% productive every day. Of course, you still need to pay them for eight hours per day. However, for the purpose of your schedule, you should factor in the productivity factor as well.
Let’s look at an example. Let’s say you have an activity that is estimated to take 80 hours of effort. If an employee is applied full time, it may take him or her a little over twelve days (80 / 6.5 productive hours per day) to complete the work. If a contract resource is allocated full time to this same activity, the activity duration would be eleven days (80 / 7.25 productive hours per day).
Agile began with the promise to make smaller project teams more able to react to ever changing customer requirements. But what if your project is big? I mean really, really big. Can we have scaled agile?
This interview about Scaling Agile with Andrew Burns, PMI-ACP, PMP, was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss his paper and presentation Dragon Scales: 50 Teams Scrumming -- Implementing Adaptive Project Management Practices at Scale. Here is the abstract:
Product portfolios can easily scale to 50 teams or more in meeting large organizations’ needs. Large portfolios with strong foundations are derived through values-based leadership. The technique links corporate and individual values to scientific principles. Scientific principles inform us that change is constant and therefore adaptation defines good practices. Values-based leadership’s agile practices take root, thrive, and adapt at the pace of business change.
The three-hundred software engineers considered herein innovated within a portfolio of 18,000 colleagues. Their agile, adaptive product development practices continue to evolve from plan-driven provenance. Leveraging agile practices at the portfolio, program, and project level continually unleashes innovation, quality, and throughput of value. Though contextualized in terms of software product development in the 2010s with Scrum, the message of innovation through values-based adoption of scientific principles is timeless and framework unallied. Implementation of practices observant of values and principles endures as a way to deliver the best products regardless of toolset.
Is Your Project Even Feasible? Here is How to Find Out
Most people are aware of a Business Case. The Business Case allows you to define a project at a high-level, yet with sufficient enough detail to know whether the organization wants to provide funding. However, sometimes the sponsor is not certain of the costs and benefits, or even if the project is feasible. This is a good time for a Feasibility Study.
A Feasibility Study is used to explore whether a project makes sense or not. The Feasibility Study looks at more than cost and benefit. It looks at whether the project is feasible in a number of areas.
There are a number of areas of feasibility that should be analyzed.
1. Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.
2. Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.
3. Operational. Can you operate the project solution? It is possible that the project itself is feasible, but you may have significant risk in being able to operate the solution after the project is over.
4. Geographic. Is the project feasible given the physical location of the project team or the customer?
5. Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project.
6. Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?
7. Legal. Are there any legal problems that will make this project unfeasible?
8. Political. Are there any internal (or external) political problems that will make this project unfeasible?
Recommendation. You may explore a number of alternatives for structuring the project before ultimately drawing your final conclusion and recommendation. The recommendation may be that the project is not feasible. The sponsor and management stakeholders may choose to accept the recommendation or move another direction.
If the project appears feasible, the sponsor would proceed to develop the Business Case based on the final recommendation. The Business Case should address the costs, benefits, risks, assumptions, and other information to finally determine if the project makes business sense.