By Rob Redmond Almost every assigned task that has any complexity to it requires working through issues. Consider The Onion Rule: Simple tasks often fall apart like onions. What should require five minutes will inevitably require 10 days to accomplish. If your boss assigns you to do something as simple as update the status on a ticket, you will inevitably have an experience such as the following: What should require five minutes will probably require 10 days. We have all had such an experience. Many of us find that we peel onions for a living. We peel and peel, and eventually we reach the center, but only after littering a hundred layers of dry wrapping on the ground. Managers must work to eliminate the effects of the Onion Rule from their operations at every opportunity. We keep experiencing the effects of The Onion Rule everywhere that we go in our companies, but do we ask ourselves if our own desks cause this effect upon others? Do people have this sort of experience when they approach you for help? Wherever possible, reject the onion. Project Managers have an obligation in their planning to foresee and schedule for the inevitable Onion Rule effects that their participants are likely to encounter. When documenting roles and responsibilities, it is wise to ask questions such as: Rob Redmond studied sociology, psychology, and political science as an undergraduate before entering the workforce. Returning to school, Redmond earned an MBA from Georgia State University in June of 2000. Rob is currently employed as a manager of IT of a large technology company. Rob runs the struggling manager blog where he posts about his experience in both management and project management. June 2, 2009 | Author: PM Hut | Filed under: Project Management Musings
The Onion Rule for Project Managers
You love your laptop, right? It goes where you go and it's oh so handy for meetings. Well, personally I'm a pen and paper girl but if it's really important and will make things easier I will tote around my laptop and use it in meetings. Not using it for every meeting makes me acutely aware of some of the bad habits people adopt when they use their gadgets around other people. Remember, being an office goddess is all about making it look easy, seamless, effortless. So don't get side-swiped by gadgets: follow these tips for office gadget etiquette. Laptops Phones and BlackBerries OK, no excuses now. Set a good example for everyone else!
May 27th, 2009 written by Elizabeth Harrin for PM4Girls.elizabeth-harrin.com
This month in the Office Goddess series, I want to look at using your gadgets at work.
I thought this might be an interesting topic to write about. Really…how many of us said that we wanted to be Project Managers when we grew up? I was going to be a baseball player, then a racecar driver, then a lawyer and when I first entered college – a pharmacist, believe it or not. I switched to the MIS track and came out of college as an application developer. The Beginning My first 3 or 4 years were spent coding in COBOL and writing proposals for long-term government contracts. After one of those contract wins, I took the role of Configuration Manager on the project. I'm really dating myself here, but in the early 1990's I switched to Project/Program Management when I was offered a key position on one of the contracts we were performing on with the US Department of Education. Couldn't Code Forever I recognized early on that I wasn't truly interested in coding forever. I needed the interaction with the customer and to lead projects and oversee tasks from beginning to end from a higher viewpoint. I jumped at the chance to become the Configuration Manager on the Guaranteed Student Loan project we had just won. I managed all change control for the project including leading the formal Change Control Board and managing a small staff. Switching to the Project Management path came a couple of years later but was still more like Program Management than Project Management because it was really overseeing on-going activity on a five-year government contract, not running multiple engagements from beginning to end like I think of more traditional project management roles. My first taste of performing the type of project management that I perform now came in 1998 when I went to work for Rockwell Collins handling their internal internet, intranet and extranet projects and leading a small team of web developers on these efforts. I thoroughly enjoyed the challenge of overseeing those projects from beginning to end – even handling the 'sales' side on these internal projects and sometimes managing up to 10-15 live projects at a time. Except for a stint as a Corporate Applications Development Manager for a large gaming/hospitality entity here in Las Vegas, I've pretty much stayed in the project management track handling usually 4-6 projects at a time. I like the challenge, I love the customer handling and interaction, as well as the oversight responsibilities for the delivery team. I've found my niche…I've found what drives me. When I need a taste of innovation, I've been able to get that from consulting work with smaller organizations helping them either organize their PM practices, incorporate new or better practices, fix problems they are having with customers and solutions and in some cases just help them figure out a better way to do business. These activities don't really follow a PM path so they tend to feed the entrepreneurial spirit in me. Early Mentor My real career turn from developer toward project manager came from my early mentor/manager who discussed my career path at great lengths with me on many occasions. From my answers could tell that I was aligning more with a project management interest. He helped guide me in that direction and helped me to find roles on proposals and other projects that would get me the experience and the foot-in-the-door situation to be able to move into those types of roles. Your Feedback That's my story in a nutshell. I welcome any questions you might have and I'd also like to hear how some of you became project managers. I still haven't had any of my kids say they want to be a project manager when they grow up so I know it's a discipline you really just 'happen into' more than choose, for the most part. Go ahead…send me your stories. Published by Brad Egeland | May 26, 2009 for PMTips.net
Communication is vital in project management. In fact, I'd say good communication skills are one of the most important qualities a project manager can possess. But is a project manager getting involved in the internal communication of the project team actually providing value? As a quick thought experiment, let's imagine a team of five members. In a self-organising team, it may be that each member has a discussion with every other member to let them know where they are up to, what they are working on, etc. This communication, in one direction (i.e. person A telling person B their situation) takes an amount of time I'll call t. I have shown this situation in the 5 person team in the diagram. In this situation, each person talks to every other person. There are 10 conversations, each taking a time of 2t. This means, with two people in each conversation, the total work timeused is 40t. In other words, adding a project manager reduces the time the team spends in sharing information by half - in this particular case. This reduces the total time taken to just 5t, but the total work time is only reduced to 25t - it only takes person A time t to update the other 4, but each of the 5 has to be there, a total of 5t work time. This is repeated for the other 4 people. In a team with a manager the total work time would be higher - purely because the project manager has to sit in the meeting too. If, however, the project manager receives updates from the team members individually (for a total work time of 10t) and then feeds back to the entire team (for a total work time of 6t) then we have a total work time of 16t - again less than in the self-organising team. We can easily expand this up to teams with 10 members. In this case, team members holding individual conversations gives us a total work time used in communication of 180t, a team holding a meeting gives a total work time of 100t, while a team using a manager and meetings takes a total work time of 31t! At this point it all looks cut and dried - self-organising teams, even if they use meetings, spend far more time in communication than a managed team. Of course, that's only true when you have been as grossly unfair with the figures as I have. (Using pseudo-scientific methods and information to draw unfounded conclusions is fun!) The most obvious way I have been unfair is assuming the project manager can condense down everything all the team members need to know massively. In the model where the manager has a conversation with each team member, I have decided the information which the other team members took 4t to pass to him can somehow be condensed down to only take t for him to pass on! This seems rather unlikely… So no, I'm not saying these figures are going to be accurate. But they do illustrate some important ideas. In other words, you need to be more than good at talking. A project manager needs to understand the project well enough to know who needs to know which pieces of information, and just as importantly, which pieces of information are of no use to other members. You need to act as a filter, to make sure you're not wasting the time of your team members. Communication isn't about how much you say to everyone, it's about saying the right things to the right people. This post written by Trevor Roberts for projectmanagementguide.org
Now, the communication cannot be one way - person B also needs to tell person A what they are up to. So they also take time t to pass that information on. So the total time for the update conversation is 2t. But the totalwork time is 4t - i.e. 2t for each participant.
Now let's look at the situation when we add a project manager. In this case, I have assumed each team member tells the project manager where they are up to. The project manager then evaluates the information, and feeds back to every team member. The two way conversation thus still exists, though the two ways may happen at different times. In this model, there are 5 conversations, each of which take time 2t, giving a total time of 10t, or a total work time of 20t.
Of course, there are other possibilities. It may be the self-organising team shares information through a meeting, rather than separate conversations. This would dramatically reduce the total time. In this model, person A tells all the other members of the team what they are doing at the same time. Then person B does so, and so on.
The function of the project portfolio management office is to manage the organization's project portfolio, which typically includes prioritizing projects, allocating resources to projects, and tracking the performance of the project portfolio. A key focus is ensuring that the overall collection of projects maximally supports the objectives of the enterprise. In addition, the office collects and distributes data for reviewing, assessing, and managing individual projects to ensure that they are meeting their expected contributions to the portfolio. As illustrated in the figure below, portfolio management provides the necessary link between project management and enterprise management. Miley W. (Lee) Merkhofer, Ph.D., is an author and practitioner in the field of decision analysis who specializes in assisting organizations in implementing project portfolio management. He has served on advisory panels for several government agencies and has received grants and research awards for work in the area. Lee is an editor of the journal Decision Analysis. Prior to becoming an independent consultant, Lee was a Partner of PriceWaterhouseCoopers, where he founded that organization's capital allocation and project prioritization business practice. Lee is a founding partner of Folio Technologies LLC, a provider of web-based, project portfolio management software. Lee received his Ph.D. in engineering economic systems from Stanford University. He is the author of the book Decision Science and Social Risk Management and co-author of the book Risk Assessment Methods.. Additional papers on project portfolio management can be found on Lee's website,www.prioritysystem.com. E-mail: lmerkhofer@prioritysystem.com. May 26, 2009 | Author: PM Hut | Filed under: Project Portfolio Management for PMHut.com
Some time back I was responsible for a portfolio of projects being done within the finance organization of my company. One of the projects was outsourced to a large consulting firm who supplied the project management, analysis, and development resources to the project. I would hold weekly meetings with the project manager who consistently gave me a “thumbs up” on the project up to the first key milestone being hit. When the week of the first milestone approached, he announced that the milestone was going to have to slip by a week to ensure successful delivery. The next week came along and again the project slipped a week. This went on for two more weeks with the promise of “we’ll for sure nail it next week.” I decided to do some crawling around the project to assess where the project was really at. Turns out we were at least a month away from delivering to the milestone which was already a month late. Needless to say I was less than thrilled with the consulting firm running the project. They sent out one of their heavyweight project managers to assess the situation. After two hours of reviewing the project he reported back to me that the project had slipped, not due to anything his organization had or hadn’t done, but because of things we as the client did to cause the problems. Needless to say I pretty much lost it with him. I then went through the project plan with him and went through each task and peppered him with questions about why his project manager hadn’t managed the execution of the project and why we were continuing to get a ‘thumbs up” when in fact the project had slipped horribly. After my inquisition he said he’d follow up and get back to me. I’m still waiting. Ah, the best laid plans of mice and men often go awry. Despite how pretty a project schedule looks, how clear the organization chart is, or how well articulated the risks and issues are, the most successful projects execute great to a great plan. Solid project management execution means driving the plan, making adjustments as necessary to address unforeseen issues, and removing roadblocks which can inhibit successful completion. The project manager has to stay steady at the helm making sure these things happen; they won’t just happen by themselves. To articulate this a bit more here are three formulas for you to keep in mind: Execution - Planning = Randomized Flailing Through my experience I’ve come up with six techniques that can help you as a project manager better ensure project success. While this isn’t an exhaustive list of everything you can do, it does highlight some specific areas which can help keep a project from derailing: Snuff out and squash “shiny objects” - First, let’s put shiny objects in context; to me a shiny object isn’t important to the task at hand and isn’t time-sensitive. If something comes across your desk that can be done later without impact to your work, yet interrupts what you’re doing, then this in my view constitutes a shiny object. It’s also important to distinguish between shiny objects and the garden-variety fire-drill. The primary difference to me is a fire drill needs to be done immediately, otherwise there is some material and tangible business consequence; whereas with a shiny object there is no material and tangible business consequence if it doesn’t get done. This is an important distinguishing factor because many shiny object violators I know view their shiny objects as fire drills and take comfort in responding to fire drills because of the sense of accomplishment they feel in putting out the fire. Be on the lookout for shiny objects and squash them before your team gets derailed. Watch the “off-workplan” tasks - Recently I worked with a project team that had a pretty decent project plan with dependencies, resources, and timeframes all laid out. The problem, though, was that the project plan assumed 100% resource focus but only about 60% of the resource focus was dedicated to the project plan. The other 40% was consumed via to-do lists which the project manager kept in addition to the project plan. Thus, the project was doomed to a 40% schedule slip right from the get-go because of the to-do list tasks. As the project manager, you have the responsibility of ensuring that all project-related activity is reflected in your project plan and that you specifically articulate the percentage of time resources are dedicated to tasks. Think realistically aggressive when developing estimates - I’ve worked with three distinct personality types when it comes to estimating levels of effort. The first personality type is Ms. Reality. She looks at a given set of tasks and develops a realistic yet aggressive expectation of what will be required of her to complete the task. More importantly, she hits her dates with a high degree of reliability. The second personality type is Mr. Op T. Mystic. Mr. Op consistently under-estimates tasks and provides a “if all of the stars align” projection on completing tasks. Tasks quickly get to 90% done then stay there forever. The third personality type is Mr. Gloom N. Doom. Mr. Gloom typically provides worst-case estimates and will slather on contingency like barbecue sauce on ribs. The secret sauce (can you tell I really like ribs?) here is to recognize the personality type you work with and try to snuff out reality with each personality type. Sure, you’ll get some push-back particularly from Mr. Gloom, but unless you apply some aggressive reality to your estimates you’re going to have a hard time getting sponsors and higher-ups to view you as a credible project manager. Hold weekly status meetings - I am a big fan of weekly status meetings and weekly status reports, particularly on high-visibility projects. In fact, I have become a strong proponent of creating my project status report (see my status report template at the bottom of this article) right in my status meeting. Key to this is focusing on project plan tasks, milestones, risks and issues during the status meeting. I’ve been through way too many status meetings where the focus was on each team member talking about accomplishments and effort versus results. Now, it’s nice that all of the team members are working so hard, but when everyone starts patting themselves on the back for how many hours are being worked at the expense of managing to schedule, you’ve got a sick project on your hands. Keep the status meetings focused on schedule, risks and issues and keep them very regular. Don’t let weeks go by without doing them unless you’re willing to play Russian Roulette with your schedule. Expose the violators - So okay, before I have every HR manager ready to shoot me let me explain what I mean. In status meetings, I think it is completely within bounds for a project manager to expect project team members who don’t deliver on their commitments to explain to the project team why they aren’t pulling their weight. Too many times I’ve seen project managers shield slacker project team members or not force them to explain their actions (or inaction as the case may be). What each member of the project team needs to recognize is when he or she doesn’t perform it isn’t just the project manager that is being let down; it is the entire team. When each project team member feels accountable to the rest of the team for delivery and directly feels as if he or she is letting the rest of the team down he or she is more likely to perform and meet dates. This can be very effective in getting teams to perform, just make sure it is done with respect. It’s about getting teams to perform, not about skewering someone’s dignity. Excellent planning coupled with strong execution is crucial to ensuring the success of any project. Subtract planning or execution from a project, and you either get the randomized flailing of a project out of control, or the well-dressed inertia of a good-looking project going nowhere. Lonnie Pacelli is an internationally recognized project management and leadership author and consultant with over 20 years experience at Microsoft, Accenture and his own company, Leading on the Edge International. Read more about Lonnie, subscribe to his newsletter, see his books and articles, and get lots of free self-study seminars May 27, 2009 | Author: PM Hut | By Lonnie Pacelli via PMHut.com
Planning + Execution = Project SuccessPlanning - Execution = Well-Dressed Inertia
Once opportunities have been identified, with relevant information normalized and made easily accessible, individuals throughout the organization with broad understanding of the business can provide "reality checks." Summary measures conveying data related to cost, risk, and benefit can be used to create graphics and comparative analyses that allow decision-making teams to collaborate on project-selection decisions. picture via blogs.zdnet.com Organizations invariably find that creating their first inventory of ongoing and proposed projects is revelational, "I didn't know we had so many things going on, no wonder we can't get anything done!" Counting projects produces instant value. If you schedule 130% of your human resources to projects, for example, you can be assured that some things won't be done. Reducing the number of projects eases the strain on common resources, giving remaining projects the resources they need and eliminating time spent by managers in negotiations over the people and other resources. The initial project inventory often uncovers significant duplications and mismatches. For example, when Schlumberger (a major energy company) first grouped IT projects, they found that 80% overlapped. Duplicate efforts should be eliminated, obviously, and similar projects combined into a single project. Schlumberger reportedly saved $3 million just by eliminating project redundancies. Looking at projects from the perspective of the portfolio makes projects look less like discrete efforts and more like a connected suite. Information and understanding is improved. Interdependencies among projects can be noted. New requirements can be evaluated against current commitments. Portfolio analysis allows investigating questions like, "How are resources for Project A impacted if Project B is delayed?" The portfolio extends the focus beyond individual project management and highlights objectives and goals. Recognizing project portfolio management as an ongoing activity creates a shift away from typical one-off, ad hoc approaches to project management. The portfolio establishes a philosophy and culture that enables visibility, standardization, and measurement as a means for process improvement. The following hierarchically summarizes these and other benefits typically observed from implementing project portfolios. Miley W. (Lee) Merkhofer, Ph.D., is an author and practitioner in the field of decision analysis who specializes in assisting organizations in implementing project portfolio management. He has served on advisory panels for several government agencies and has received grants and research awards for work in the area. Lee is an editor of the journal Decision Analysis. Prior to becoming an independent consultant, Lee was a Partner of PriceWaterhouseCoopers, where he founded that organization's capital allocation and project prioritization business practice. Lee is a founding partner of Folio Technologies LLC, a provider of web-based, project portfolio management software. Lee received his Ph.D. in engineering economic systems from Stanford University. He is the author of the book Decision Science and Social Risk Management and co-author of the book Risk Assessment Methods.. Additional papers on project portfolio management can be found on Lee's website,www.prioritysystem.com. E-mail: lmerkhofer@prioritysystem.com.
By Miley W. Merkhofer via ProjectHut.com
Benefits of the Project Portfolio for Executives and the Business
Benefits of the Project Portfolio for Program Managers
Benefits of the Project Portfolio for Project Managers
