Does your organization document and share its lessons learned throughout the project management process? This question was recently discussed among a highly engaged group of project managers through the Project Management Networking Group.

Information sharing is a proven essential step for improving the project management process – emphasizing the need to not only to discuss and share lessons learned, but to document valuable insight for future reference. (The PMI discussed a similar issue last year.)

According to Bill Gutches, author and producer at Opinions Are Free, “Insanity is defined as repeating the same things over and over again and expecting different results!” This post is intended to help PMs avoid such scenarios.

The PMI also posted a similar topic last year, and documented insights about collecting and implementing lessons learned to improve the project management process.

Voices on Project Management

Below is the collective insight from the community about how to most efficiently share PM lessons learned, including whether or not this is a good idea and use of resources across the organization:

• Conduct monthly PM meetings, allowing opportunities to share lessons learned for PMs across the company, department or office. The response will generally be positive and will most always generate discussion. Sharing is only part of the process…you must get your PMs to refer to lessons learned early and throughout projects.

Jo Musto, project manager at Stryker

• Organizations must “institutionalize” the lesson. Once a lesson is identified, assign a champion to make it become an organizational lesson learned.
  

William Pirkey, T Project Manager & Software Engineering Manager

• Implement and continue to revise in order to maintain the learning. What happened after implementation? Did something new crop up? Some organizations may have an intranet or document records space where this can be recorded. Or it might be simple enough to start a wiki to record all these lessons. This will allow different team members to share their experiences. The key to learning is to share, implement and then keep practicing!

Shubangi Paheerathan, Customized training in project management, written & verbal communication

• Lessons learned must be documented at the end of each project life-cycle phase, must be stored in a way that facilitates retrieval (NOT stored by project name) and there must be a mechanism in place that requires PMs to consult past lessons and penalties/disincentives for failing to apply lessons learned.

Bill Duncan, IPMA-B Assessor

• Retrospectives on the process must be done at the end of each iteration, not just at the end of the project. The entire team is involved and participates in a (15 to 30 minutes) well facilitated retrospective, while the team picks up changes they can commit for the next period of work (1 -4 weeks on what you have picked as your cycle time).

Bachan Anand, Believer, Agile Coach

• People should be commended for bringing things to the attention of others that we should avoid doing, and promoting best practices. The worst crime is to cover things up that you would rather others not know and damage the organization’s development as a result.

Derek Bell, PMP (APM & PMI) PRINCE2 Practitioner

• “If you do not learn from history, you are doomed to repeat it.” In order for a group of people to get better at a repeating or similar sets of tasks, they MUST review what worked and what didn’t as often as possible AND use the results of these reviews to change what they plan to do next. Here is another useful quote: “Insanity is defined as repeating the same things over and over again and expecting different results!”.

Bill Gutches, Author and Producer at Opinions Are Free

 

Guest post by Jennifer Whitt, PMP
Founder of PDUs2Go.com and CEO of Optimo.

In this post, guest author Jennifer Whitt discusses how to proactively avoid turbulent times as a manager, while highlighting how to steer your team back to calm waters when faced with a hazardous path. Jennifer is an accomplished speaker, author and expert on team and leadership development.

Have you ever been white water rafting? There are times when the pace is slow, the river is smooth and you remain perfectly dry. There are other times, however, when you are… white water rafting. Hazardous drops, large waves and even larger rocks require that you use considerable skill to maneuver around these dangers. In situations like this it is good to have a talented guide on the raft with you barking out commands in real time.

Sometimes our projects are like white water rafting. There are times when the pace may be slow(er) and the meetings may be routine. A weekly status meeting with a couple of email updates in between may be all that is needed to keep everyone on the same page. However, what do you do during those times when the water gets a little rough? The pace of your project picks up, facts may be changing every hour and information gets stale fast. During this time, mistakes can be costly. This is when the PM needs to act as the talented guide and provide clear direction in real time.

Below are three suggestions you can use to communicate in the ‘here and now’ and keep your project team up-to-date with the most recent information:

• Set Up a Beacon that Everyone Looks to For Direction – Establish who, and only who, will be providing direction and information during this turbulent time. Logically, it is the project manager. However, there are some managers who feel their job is to serve as a scribe who takes notes and not provide direction. If you find yourself in that category, this is your chance to step up, take ownership for providing direction and start issuing commands to get everyone through those rough times. People do not mind being told what to do if they trust you and know your intent is to help everyone across to the other side.

• Establish a Common Fact Set – During bumpy project times, there is a lot of misinformation that can throw the team off course. Establish a common set of facts that everyone knows to be true at that moment in time and provide updates regularly. Good decisions can then be based off this information. It is understood that the facts may change, but by providing this up-to-the-minute information, you make sure everyone stays current.

• Do Not Overwhelm the Team with Too Much Information – You know what it is going to take to get everyone through this unsteady time in a project, and you know your team trusts you. Be careful to not overwhelm them with too many details about how you plan to get them to the other side. Have team members concentrate on the next three to five immediate steps. Otherwise, they may lose focus and mistakes may be made.

While following the three suggestions above will not guarantee that your projects will never see tough times, they will help you navigate in real time without tipping the boat over.

So, what are some things you have done when you need to communicate in real time? What technologies you are using to keep everyone up-to-date? For example, how do you use SharePoint, Instant Messaging or even the private side of Twitter with your project teams to relay up-to the-minute information?

About Jennifer Whitt (PMP)

Jennifer Whitt is the founder of PDUs2Go.com, provider of self-paced downloadable courses for project managers ‘on the go’ to earn PMI PDUs. She is a speaker, trainer, Certified Performance Coach, author and president of Optimo, Inc., a consulting firm specializing in team and leadership enhancement as well as project management.

For almost twenty years, Jennifer has tackled the challenges that come with managing individuals, teams, and multimillion-dollar projects. She is a member of the National Association of Female Executives, Women in Technology International and Atlanta Chamber of Commerce.

In this two part series, Jeff Hodgkinson will identify how leadership style is a primary success factor for collaborative efforts. Jeff explains three styles of leadership (Decision-Making, Activity Management, Personal Authority) while explaining 15 sub-categories – after reading, try to identify how your method stacks up against your peers.

It is a ‘soft skill’ which is often neglected in training because it is very hard to measure a person’s leadership style in a training situation. By understanding leadership styles and their impact, a manager can become a great project leader. Therefore, these managers must determine the most appropriate leadership style for each project team. A program/project manager (PM) should choose the correct leadership style based upon the project and project team requirements. Some of the most common leadership styles include:

1) Decision-Making Styles

Autocratic: Makes decisions without input. This leadership style is seldom warranted, unless the PM clearly knows more about the subject matter and has immature and inexperienced team members. That is seldom the case, and if it is true the individual has made poor selections for team members. Someone who uses an autocratic style outside a ‘life or death emergency’ project should re-examine her/his overall methodology and motivation.

Consensus: Solves problems and makes decisions in group with decision-making based on group agreement. Unlike Democratic, this leader will not necessarily take a vote, but will rather lead discussions, ‘read’ the team position and personally make the decisions accordingly. This style is less formal than Democratic. It may work better for dispersed or virtual teams which cannot meet together frequently.

Democratic: Invites ideas from the team for decision-making process, goes with majority. Also known as Consultative or Participative. This style will usually result in a good decision, but may leave the minority voters disgruntled. It is important that the manager reach out to the minority voters to ensure that though they disagree with the decision, they commit to the outcome. A mature leader will never hold a vote without first consulting with the primary stakeholders in the vote. This is necessary to ensure that the vote properly addresses the issue at hand, and that all parties (including the manager) know what is at stake.

Laissez Faire: This French phrase means “leave it be.”  This style is a hands-off policy and the team is entirely self-led regarding the decision making process. Except in a very mature self-motivated team, this may lead to aimlessness and lack of success. Less mature team members may view it as a lack of interest or involvement by the PM.

2) Activity Management Styles

Directive: Tells others what to do.  If this style is warranted (but it seldom is) the manager must be very diplomatic and use a personal authority style which will not alienate team members. This style may be warranted in the case of an immature team, immature team members or an extremely time-critical project. However, this style is generally not preferred because it does not develop the team nor allow adequate feedback from the team. Mature team members will resent this style and productivity will be lower in the long run.

Bureaucratic: Runs projects “by the book,” ensuring the team follows procedures exactly. Some situations may call for this leadership style, such as a government contract or where regulatory requirements must be met. Usually, though, this style is the refuge of insecure project managers who fear accountability for variations from the standards. Projects may benefit from variation from published standards, if those variations can be justified. A consistently bureaucratic leadership style may indicate poor ability to manage risk or apply the value of informed risk-taking.

Coaching: Instructs and motivates others to enhance their skills to achieve maximum impact for the team and project. A coach is directive, but focused on individual and team development. This is very good as long as it is also in line with project goals. A manager’s first responsibility is to the project, and secondarily to the team and individual. Note that a ‘coach’ and a ‘mentor’ are not the same thing. A mentor’s first responsibility is the individual’s career and personal development, not to the project or team. Generally, team members respond well to a coaching style, and this style may benefit future projects as well as the current one. As harsh as this may sound, a good PM must be willing to delay a team member’s personal development if it interferes with the objectives of the project. For example, a PM may ask a team member to defer taking a class to acquire a new skill if that skill is not needed to complete the project on schedule.

Empowering: Gives team members authority and tools to do their jobs. This is similar to a coach, but is less focused on teaching and directing. In contrast to a Directive style, the Empowering leader asks team members to make decisions, to choose tasks, and even to determine how those tasks are done. This person evaluates the maturity and skill of individual team members and gives them appropriate levels of authority and freedom to accomplish the project goals. An Empowering PM helps team members learn skills needed to accomplish project goals or acquire needed tools to do their jobs.

Facilitating: Coordinates the input of others. A facilitating leader is primarily an organizer and dispenser of project information. This person does not make decisions for the team, exert authority nor direct activities. He/she simply is a contact point for team members to coordinate their individual efforts. Generally speaking, this person has little personal authority, and simply communicates the decisions or orders of higher management. This style is appropriate for a novice manager, but may also reflect a lack of management support for true collaboration-leadership discipline.

Laissez Faire: Leaves the team alone. Has a hands-off policy and the team is entirely self-directed in their activities. As with a laissez-faire decision-making style, this style is only appropriate for very mature self-motivated teams. For any other team, it is a formula for failure and a sign of lazy or over-tasked leader. Team members will generally interpret this style as a lack of interest, and the project will suffer accordingly.

Supporting: Provides assistance along the way. This individual is more of a teammate than a leader, but may have great success as a result. He/she pitches in and does some of the actual work of the project, as well as coordinating the project overall. Frequently, this style is combined with the Facilitating style.

To be continued…

Jeff Hodgkinson is a Senior Program Manager at Intel. He is a 30 year veteran with Intel and holds an MBA along numerous credentials in Program and Project Management including the IPMA-B certification. He is located in Chandler, Arizona, USA.  Jeff or ‘Hodge’ is known both inside Intel and in the PM community for his successful coaching and mentoring of aspiring project managers.  You can read more about Jeff per his profile on LinkedIn or follow his handle on Twitter.

Most people know that one of the major roadblocks to healthy relationships – professional and otherwise – lies in avoiding tough conversations. When managing a team or a trying to execute a project, the detriments can be far-ranging and involve a lot more than just personal discomfort.

Paul Pantzer, a senior consultant in program management at Molecular, wrote an insightful and helpful article on the topic and how to go about weighing the trade-offs between doing nothing and risking an awkward exchange.

Here’s a quick summary of his 5 tips:

1. Identify the 1 or 2 top topics you’re avoiding
2. Identify why you’re avoiding them
3. Consider the result of doing nothing
4. If the “do nothing” risk outweighs the reason for avoiding the topic, schedule a conversation to address the issue
5. Before tackling the conversation, acknowledge that it is a difficult one and try to explain why

The full article is definitely worth the read. You can find it here on the Projects@Work site, a good source for news and best practices in project management.

Guest post by Addie Monson, PMP
Director, Enterprise Project Office, Chase Paymentech

We know Addie Monson as a veteran and leader in PM practice and collaboration. She has several years of experience implementing Daptiv solutions in her practice with Chase Paymentech and she generously agreed to share her insight on the evolution of project management with us. We hope to have her contribute more lessons and tips in the future. Thanks Addie!

1. PMBOK – Not just for the big boys anymore
2. PMPs for everyone
3. PMOs outside of IT
4. Collaboration via the Web
5. Results – The proof is in the project

1: The PMBOK – Not just for the big boys anymore
It used to be that the world of project management was an exclusive club of engineers and systems analysts who designed 747s, military contracts or rolled new Cadillacs off the assembly line. Sure, those project managers are the veterans – they have been in the industry for 30 plus years, who learned supply-chain automation at Ford and Lockheed, then applied the principles of managing projects on time and to budget before the term “best practice” was even a whisper in every conference room in America. Today, mid-level managers in mid-size companies know what a “phase” is, understand what lag and dependencies are and can build a complicated work breakdown structure without even really knowing that they are. The PMBOK isn’t a dust collector on the shelf.

2: PMPs for everybody!
In the 90’s, every help desk analyst had their MCSD and took online courses in UML and Rational Rose. Today, PMP (synonymous with pulling all of the pieces together and executing a plan) succeeds the signature line of nearly  360,000  working professionals age 25-45 (yours truly included). Being a certified Project Management Professional by the Project Management Institute does hold a certain weight in our arena. Can you effectively manage projects without having your PMP?  Sure. Does it help you speak intelligently about the science behind the practice? Absolutely.

3: PMOs outside of IT
Traditionally, project management has been associated with complex product launches. Pharmaceutical companies, manufacturing, and of course, software development.  Waterfall development schedules to Agile methodology, all of it applied the concept of planning something, building something, testing something and introducing it to users. It made sense that the “shop” where that something was built (often Information Technology) would run its own project office.  Recent shifts to operate PMOs outside of IT – PMOs that service the entire company including technology, marketing, product development and operations – have broadened our scope of influence. It has de-mystified the inner-workings of how projects are governed and executed. It has made us more accessible to the business which we serve.

4: Collaboration via the Web
Collaboration. We learned it in kindergarten when we had to all bring something from home to contribute to the Thanksgiving dinner just like the pilgrims. We tried to practice it during college, planning our sorority formals and serving on faculty/student committees. Knowledge sharing has come a long way from the listserve days on Compuserv and discussion forums or bulletin boards on specialized topics. The Internet and its tools, from Wikipedia to Twitter, have brought the concept of asking questions, sharing information and document version into the hands and every day use of corporate America. As project managers, we don’t have to constantly pull information out of one team member and push it back to other team members. The ability and the responsibility lie with the project members themselves. I think the one thing project managers need to do more of is encourage and incent our business partners to leverage these collaborative tools. It will only make our jobs easier.

5: Results – the proof is in the project!
The single most influential aspect of project management today is, truthfully, the project managers. You can throw the PMBOK and processes at anyone, you can send someone through PMP boot camp, you can teach them how to use process modeling software – you can’t make someone a leader. If project managers weren’t effective and didn’t achieve results, there wouldn’t be value in what we do. Businesses today need project managers to get it done. We facilitate progress. We remove “show stoppers.” If we don’t apply the best practices, promote the collaboration and practice the science of managing the litany of work that needs to get done, companies won’t see the results they need. What they need is to stay viable, be bleeding edge technologists, improve hospital management practices and continue to bring the next “have to have it” product to the market. We get results, and that has made the biggest impact on project management today.

Addie Monson is the director of the Enterprise Project Office at Chase Paymentech Solutions. Chase Paymentech, a subsidiary of JPMorgan Chase, is a global leader in payment processing and merchant acquiring, capable of authorizing transactions in more than 130 currencies. Addie’s work with Chase Paymentech has been recognized by industry awards such as Computerworld’s Best Practices in Business Intelligence and she has presented at various industry events on the topic of the evolution of work and project management, including Gartner’s 2009 Project & Portfolio Management Summit.

 

There seem to be a couple of immutable truths in the PMO world, especially in IT departments. First, there is always more work than can possibly be done. This usually surfaces in the form of an insatiable appetite for projects. Second, no matter how you prioritize the work, someone's going to be unhappy - and they'll try to make your life miserable by becoming the squeakiest wheel in the company.

 

The answer, as we PMO practitioners all know, is to elevate the prioritization decisions up to the company executives. This usually means some sort of cross-functional steering committee or other governing body. It's great theory, with one major flaw. Those execs don't readily participate. I can't count the number of poorly attended steering committee meetings I've run across. The execs either don't show or send a lower ranking delegate not empowered to make decisions. Which leaves the steering committee pretty powerless, and results in the CIO once again making the decisions. And once again taking the heat.

 

So, how do you get these all-too-busy executives to pay attention and take responsibility for prioritization? The best process I've found is what I call "shock therapy for the executive team", and it involves three steps: Presentation, Argument, and Decision Time.

 

Step 1: Present the problem. This is all about making the problem obvious. During one of my CIO stints, we were creating a new IT infrastructure from scratch. This, of course, involved many parallel projects that could not possibly all be run in parallel. So, I formed an project steering committee and invited all the VPs. All but a few sent delegates, and we made no decisions.

 

Fine. So I put together a picture of the entire architecture, detailed in big blocks the major pieces, there costs, effort, and timelines and presented this big picture to the corporate executive team at the monthly monthly meetings. I showed them the millions in costs, all the projects going live in the same month, and the amount of resources (double what we had on hand) required to get the job done. The CTO, who ran the product development group, took one look and said

 

 "Dave - if I were running this, there's no way I could do all of this at once. What are you going to do? How will you prioritize this?"

 

My response: "That's why I'm here".

 

Which lead immediately to Step 2: Argument.

 

First, the VP of professional services demanded that his CRM piece was critical and had to go live ASAP. To which the VP of Sales argued that if the SFA system wasn't put in place first, Sales would get stuck and Services would have nothing to do anyway! As you can imagine, each VP argued for there piece of the pie.

 

Which finally leads to Step 3: Decision Time.

 

I've written before about the use of various prioritization tools, such as scorecards, strategic alignment, etc. Here is where those tools finally come into play. They allow the executives, once they settle down, to look at some objective analysis to help them figure out which projects should come first. Whether that importance is based on fit to corporate strategy or critical operational needs, these tools are meant to be informative, not conclusive. You will also want to present any project interdependencies at this stage.

 

In the case above, the Exec Team quickly realized that some core processes were in dire need of automation, and that the ERP system was also the core of the architecture. Therefore, projects relating to ERP came first. The other VPs then understood why they had to wait. Even better, I was asked to present progress and new initiatives quarterly so we could decide as a body how to proceed. Note that in this case, we never even formed a Steering Committee. The Executive Team ended up taking responsibility directly!

 

I have seen this process work repeatedly, and the steps to "shock therapy" tend to follow the same pattern:

 

1 - Shock them with the enormity of the problem. And do it with graphics and simple numbers, not long lists of individual projects. If they get lost in the details here you'll be back at square one.

 

2 - Let them argue for a while. As they struggle with the problem they will realize this is way too important to delegate to their underlings, the CIO, or the PMO. They will realize these are truly strategic decisions - that's their job and they know it.

 

3 - Provide them with the information they need make these decisions. This information varies, of course, by company. So, you'll have to work with your Exec Team to figure what information is most effective.

 

And good luck - while this is easy to write about, it's no cake walk to execute. You'll be relying heavily on the relationships you've built with each executive (you have done that - right?) to see you through this process!

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

• They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used their Enterprise Program Management system for project tracking and dashboard metrics.
  
• They provided leadership training to boost the confidence of their PMs
  
• They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  
• They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in their EPM system).
  
• They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).
  
  This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  
• They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  
• They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  
• They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

"There is no Spoon" is a popular quote from the "Matrix", where the young prodigy hints to the protagonist while levitating and bending a spoon with his mind, that the spoon is a mere container of energy, and is symbolically irrelevant to reality. Media sponges that we are, we like to cling on to every catchy metaphor we run across, and frame it in our own context.

Software interaction designers have been trying to eliminate the "spoon" for years, to provide direct, unimpeded access to the raw data with which the User will interact, thereby transforming the software itself into an irrelevant, invisible vehicle to facilitate the interactions. Our predecessors, the industrial designers, have forever chased that "perfect fusion" of form and function. For the software interaction designer, the lack of maturity in this field has served as both a challenging puzzle with no concise solution, as well as an exciting time for innovation and pioneering.

I've been involved in the design of eProject's user experience since version 5.0, and with PPM6, we've finally broken through that seemingly impenetrable barrier which has impeded usability improvements for so many other software tools - priority. The information architecture and user experience of PPM6 is the product of time, research, and days on end of trying and re-trying ideas to make that "Spoon disappear". We don't want you to see the software, the user interface, or notice how many mouse-clicks it takes to get to that form. It's all about the data. Seeing and creating the data.

I initially intended this blog to serve as a "behind-the-scenes" view into the thoughts, ideas, and challenges behind the design of PPM6's user experience. However, I think it's only natural to frame this information in a way which may prove useful to you, our users.

1. If we don't know what each User needs, let people who know take care of it.
   

   This sounds like passing the buck, but it's not. You can't please everybody, but we still want to. That's why we've designed PPM6 to give the power of personalization to your Administrator. We've allowed them to control everything from what applications you have access to, to what columns you see in your views. A lot of this power has also been passed on to you. The challenge of this was providing this power without creating absolute chaos and an overwhelming user interface. You'll see a lot of drop-down menu's in PPM6 which behave like your sock drawers at home. What's in them is up to you (and your Administrator). What's important is that you use that power. Pay particular attention to the red drop-down menu that says "More Views...".

2. Don't provide confusing pathways to data. Bring the data to the User.
   

   Websites are great, but websites aren't great tools. It's a clear distinction you have to make. Websites were designed to draw users in, and encourage them to spend time there navigating, absorbing information, exploring. Software tools can't do that. The less time you spend with a software tool, the better. Since we're a web-based software tool, not a tool-based website, we don't want you to explore sitemaps, drill deeper and deeper into our layers of sections and subsections. PPM6 has only three basic areas you need to know. We've taken what was a 16 story building, and flattenedd it to a strip mall for you.

   
   
   
   • The Global Views - these are all the pages you see when you click on a tab at the top. From here, you open and work with items. That's it.
     
     
   • The Project Views - Projects are pages that only provide access to items specific to that project. Otherwise, it works just like the global views. You get to projects from a special tab called "Projects", or by clicking on a project name.
     
     
   • The Item Details - Items are shown as a popup window. Wherever you were to get to that item, you're still there. You don't need to remember how you got there, or where you have to go next. Open the item, read it, or edit the data from the same window, then close it. New items, which are created using forms, open in pop-ups as well. When you're done, save it and the popup goes away, or create another in the same window.
     
     
3. Take Action from a distance.
   

   Items in the list views now have a small blue icon which opens up a dropdown-menu containing most of the commands applicable to that item, whether it be uploading a new document version or editing an issue. Use this functionality just as if you're right-clicking on an item on your desktop. You don't need to open that word document on your desktop to delete it, so why should we force you to open up that item details to update it? Once you get used to interacting with items directly from the list views, you'll find yourself with time to get that extra latte in no time.

   
   
   
4. Take control of your data.
   

   Because of PPM6's new personalization and custom view functionality, you, the user has complete control of how your data can be displayed. This means you can create multiple, well organized views based on context and relevance, or you can create one enormous, horizontally scrolling view in an attempt to cover all bases with one shot. Whichever way you or your Administrator decides, consider environmental factors such as your monitor's horizontal and vertical real estate, your computer's relative processing power, your network speed, and to an extent, your daily user habits. It may take a couple of experimental custom views to organize the data you need perfectly, but a little up-front investment into learning the features of PPM6 and trying out different solutions can pay big dividends down the road in saved time and a pleasant user experience.

The four points above highlight some of the strategic changes to eProject PPM6’s user experience, fueled by lessons learned from 5.0 and collected usability research efforts. As a user experience designer, I feel there is always more to be done, but the few changes noted above make a big impact in the overall usability of the product, which hopefully you will see in due time.

 

In my "Maximizing IT Capacity" webinar the first poll asks "How much of your time do you log? Of the choices, "none" is the most common response, with "project time only" running a distant second. Yet when it comes to understanding resource issues, actual time is the most valuable information around. By analyzing the prior 12 months time records at PeopleSoft IT, we increased our project capacity 30%, and staved off drastic staff cuts during the Oracle battle.

 

Why is this information so valuable? Properly analyzed, it provides insight into 3 key areas.

 

Feedback to project planning

In a PMO, we tend to concern ourselves with resource allocation to projects. We also spend a lot of time estimating task effort and resource requirements. Indeed, these estimates drive our project schedules, and ultimately the delivery dates promised to our customers.

 

So, how do we know if our planning is accurate? Most project managers rely on experience, and hope they're close. But it's the empirical date from time logs that reveals that the 40 hour task that completed on-time actually took 60. People worked overtime, or borrowed someone, to get the job done. And next time, we'll estimate this task as a one-weeker again, but might not get so lucky.

 

Obviously, without tracking time, we are missing the feedback loop to our planning.

 

Analyzing resource constraints

So far, we've discussed time against individual projects. Of course, people often work more than one project, and there's a lot of non-project work to be done as well. This leads to serious resource constraints, with employees and department manages alike complaining about the heavy load.

 

And what's the first line out of an executive's mouth when asked for more resources? "Prove it!" With proper time logs, you can. And you can prove it by department, resource type, skill-set, etc. And you may discover that your networking projects suffer not from a lack of resources in general, but from one skill-set in particular. At one client it turned out they had plenty of programmers, DBA's, etc. What they were lacking were project managers!

 

Time is Money

The largest line item in most departmental budgets is payroll. Therefore, where a department spends it's time is also where it spends it's money. Analyzing time can reveal how much is spent on strategic vs maintenance, projects vs change-orders, etc.  Instead of just looking at which projects fall into the strategic, informational, transactional, or infrastructure portfolios, the entire organization's effort can be viewed this way. Put that in pie-chart report and watch the execs eat it up!

 

One of then biggest obstacles to successful project delivery occurs right at the beginning of the lifecycle – deciding which projects to approve. You take in 20, 50, 100 project requests, and then it’s decision time! What do you do? If you’re like most IT departments, one of two scenarios occurs.

 

1 - The CIO looks the list over and decides, then takes the resulting flack from the stakeholders who were denied. And often his decision is based on the squeaky wheel principle – who will squawk the loudest if they don’t get their pet project?

 

Or 2 - the CIO has had enough of being the fall guy, and either brings the list up to the executive staff meeting or forms a steering committee to make such decisions. This is a huge improvement, in that enterprise level decisions are now owned by the stakeholders. The problem is, most of these discussions degenerate into VP’s arguing over their pet projects.

 

What that steering committee really wants is information. What are the benefits of each project? How much will it cost? What are the risks if we do it? What are the risks if we don’t?

 

This brings up problem #2 – how do you perform a cost/benefits analysis on 100 project requests? That’s a bigger effort than most of the projects themselves!

 

The answer is relatively simple – create scorecards that rank each request on a common scale over a number of attributes. But before we get to that, we need one more item – a good project request form.

 

In most IT departments requests come in haphazardly. The VP of Sales tells the CIO they need a new CRM system. An email comes into the PMO looking for a network upgrade in Boston. There’s simply no uniformity to how requests enter IT, and thus no uniformity to the type of information you get.

 

A good request form provides a method and channel for submitting these requests in a uniform way. While I could write an article simply on creating a request form, for our purposes we are looking for two items:

 

1.        Business benefits. What are the hard and soft benefits expected from this project?

2.        Impact. How many departments, users, processes, and geographies will be affected?

 

Now, on to the scorecard. The idea is to rank each request in 3 areas: Benefits, Costs, and Risks. By ranking each area on a common scale, we can compare apples to apples and make some decisions. A good practice is to break each area into it’s constituent elements, create a 1-5 ranking, then create a composite score for each area using a weighted average. For example:

 

Benefits: Elements could include Revenue Increases, Cost Savings, Strategic Objective, Customer Satsifaction, etc.

 

Costs: Elements should include Incremental Costs, Resource Hours (all staff, not just contractors), On-going Costs.

 

Risk: Elements could include Geographic Impact, Business Units impacted, Number of Systems Affected.

 

The 1-5 scoring depends on the size of the organization. For example, a Fortune1000 company might score incremental costs:

1 = $50-100K

2 = $101 – 500K

3 = $501K – 1M

4 = $1M - $5M

5 = Over $5 million

 

The same idea would apply to each element. Finally, add up the scores in each area and create a weighted average. The end result should be a relative Benefit, Cost, and Risk score for each project request.

 

Who should be deciding the scores? Obviously, the requesting stakeholder has the best grasp on benefits, which is why we asked those questions in the request form. Often, IT has the best feel for costs, and can use similar projects from the past to make a quick call on those scores. And both the stakeholder and IT have information on risk elements.

 

One more quick tip on ranges: Make them broad, so you don’t get bogged down in detailed estimating. At this stage you’re looking to make some quick cuts to get your request bucket down to a reasonable level. The remaining projects can go through a more detailed analysis for final decisions.

 

If you put all those scores into an eProject Dynamic App, you can then plot them onto a classic quadrant grid using Crystal (as I've done in the PMO in a Box solution set). Anything in the high-cost, low-benefit quadrant can be tossed. The low-cost, high-benefit projects are a no-brainer – get them going! The low-cost, low-benefit projects are small and can often be squeezed in for some quick wins. You’ll have to really think about the high-high projects – but that’s what steering committees are for!

The Ten Faces of Innovation, by Tom Kelly of IDEO, with Jonathan Littman, is an excellent book on how to create a truly innovative environment (as opposed to just saying "from now on, we're going to be innovative"---which nearly never works).

Some think that innovation has nothing to do with project management---that innovation is about generating ideas, and project management is merely about executing them. In my view, this is absolutely wrong, as you will hopefully see as I share a summary of Tom Kelley's book.

All in all, there are three groups of "personas" Kelley covers in the book; The Learning Personas, The Organizing Personas, and the Building Personas. The premise is that by adopting these personas, we can achieve true innovation.

As noted in the book, it's important to note that each persona is just that, and not a "position". Some people can have multiple roles, and not all roles are needed on every project. But in general, the more roles that are covered, the more successful your venture will be.

Here are the personas, adapted from the book, with my own comments added (keep in mind that the book offers a heap of antectodal information that supports these personas---real stories from real companies).

The Learning Personas

1) The Anthropologist – Observes human behavior and empathizes in order to determine what’s really needed. Fanatically keeps lists of issues and ideas. [As Toyota's slogan goes, “Go and see for yourself.” Don’t judge by a needs survey alone.] Henry Ford said, “If I had asked my customers what they wanted, they’d have said a faster horse.”

2) The Experimenter – Likes to try new avenues, using fast, inexpensive prototypes. Not afraid to think out of the box and “fail often to succeed sooner.” Uses enlightened trial and error. Can also do "implementation by experimentation" for multi-locations by engaging remote sites in prototyping, and letting them adapt to their site as needed (as opposed to a rigid “rollout”).

3) The Cross Pollinator – Examines other industries, genres, and cultures, to mine for ideas and look for analogies. These are typically “T-shaped” people, with a deep understanding of at least one core area and a broad interest in many other topics. Well-rounded, and with many interests, these people are a core source of ideas.

The Organizing Personas

4) The Hurdler – Bends the rules to get around roadblocks. Hurdlers tend to be street smart and can cleverly work around the system, undeterred by adversity. Seemingly stubborn at times, they listen to experts, but don’t let them have the final word.

5) The Collaborator – Brings diverse groups together, even if leading from the middle of the pack. Wins over skeptics and creates solutions that cross boundaries. Breaks through silos by being the glue that holds the diverse group together. Works “with” the client instead of “at” them. Prefers to coach rather than direct, coaching behind the scenes and letting the team run with the ball and have the glory. Doesn’t second-guess people from the sidelines.

6) The Director – Assembles the right people and gives them an environment that will allow their creativity to flourish. Has good strategic vision and sets the right theme. There’s no one style that works best. Some lead with calmness and others are bundles of energy. But they all give center stage to others, love sparking new ideas and projects, aim high, and embrace the unexpected with a variety of techniques, strategies, and resources. This role can be on a specific team and does not necessarily have to have a position of “director” authority in the corporation.

The Building Personas

7) The Experience Architect – Designs the customer experience, beyond just the functionality of a product. Comes up with new and creative ways to awe the customer, yet with the same basic product functionality. An example is Cold Stone Creamery, which creates an entertaining experience where the server mixes ice cream with any number of desired toppings on a slab of cold stone. The servers even put on shows. [my added comment is that The Experience Architect can learn from observing others, even in other genres, and as such can gain from the “Cross-Pollinator” and “Anthropologist” personas.]

8) The Set Designer – Creates a fun and vibrant physical working environment that can spark creativity and collaboration. Allows employees great latitude in their personal work spaces. Avoids dull, repetitive spaces. Creates formal and informal public spaces where people can collaborate and brainstorm, with all the appropriate supplies and accommodations.

9) The Caregiver – Anticipates customer needs before, during, and after the engagement, and goes above and beyond normal expectations. Makes it easy for the customer to select the right services, provides useful and quick information when needed, insures easy accessibility by the customer, and builds lasting relationships with the customer.

10) The Storyteller – Builds internal morale and external awareness through compelling stories and case studies that reinforce key values or traits. Builds “corporate legends” that get passed around. Not “spin doctors,” the storytellers get their stories from first-hand accounts from customers or employees. Storytelling builds credibility, unleashes people’s emotions, helps teams bond, and generates lessons learned.

Well, that concludes my summary of Tom Kelley's The Ten Faces of Innovation, and its applicability to project management. As you can hopefully see, what project manager wouldn't benefit from these learning, organizing, and building personas that can lead to a better customer experience, a more satisfied team, and a memorable result?

Sure, we can (and should) still define the scope of the project, manage changes to the agreed-upon scope, and use project scheduling and budgeting techniques (we don't want to throw the baby out with the bathwater). But we can take our projects to the next level with a strong dose of innovation, and these personas are as good a way to do that as any.

I highly recommend the book to any project manager or leader who wants to take their projects to the next level.

Perception is reality. A project manager can be great at the "science" of project management, and yet still be perceived as ineffective. Often it comes down to a simple lack of presentation skills. After all, communication is 90% of a project manager's job, according to the Project Management Institute.

Here's a great site with tips and techniques for those who struggle with giving presentations. And it's geared towards Chemical Engineers, many of whom are "communicatively challenged" (how's that for political correctness).

Presentation Skills

Clearly these lessons are as applicable in the corporate world as they are in education. After all, education IS everyone's business, especially those in leadership positions.

 

OK - this week I am going to delve into a rather controversial subject.

 

There is a raging debate occurring on the PMO board at PMI about the relationship between Project Managers and PMOs. It was all started by a gentleman who posited that most PMs hate PMOs, and asking for input as to why. This has lead to two camps on the subject.

 

In the first camp are those who agree that PMs hate PMOs. There line of argument is that PMOs and the methodologies they impose are seen as a threat to the creativity of PMs, who would rather follow their own tried and true processes than conform to a rigid methodology. They are also afraid of exposing the "meta-data", mostly related to performance of their projects. The PMs do not like the added administrative overhead, including signature gathering, regular status reporting, and the like imposed by the PMO. Finally, PMs do not appreciate the portfolio view of projects and would rather be left alone to manage their specific projects to success.

 

The other camp says this is pure nonsense - professional project managers are known for bringing good, sound project management processes and discipline to the table, and are therefore fully supportive of the work of the PMO, and readily comply with and enhance the work of the PMO. They also understand that good portfolio management is key to their own success. If their projects are low priority, lack sponsorship, etc, then their chances of success fall accordingly.

 

Naturally, yours truly has weighed in on this debate. I have found that which camp a project manager falls into can be heavily influenced by how the PMO is implemented. If the PMO adopts a rigid, one-size fits all SDLC methodology (see Common PMO Mistakes on this blog), project managers will have a difficult time succeeding. This kind of "police state" PMO almost always fails, with PM dissatisfaction being one of the primary reasons for failure.

 

On the other hand, a truly strategic PMO that implements a flexible, multi-tracked methodology, properly prioritizes project demand, and matches that to available capacity, becomes the project manager's best ally. These PMOs also listen to input from their PMs to constantly improve the organization's project management processes and culture. Finally, proper automation can go a long way toward relieving any additional administrative overhead, while increasing visibility and collaboration. In short, professional project managers feel they are an integral part of these successful PMOs, and that the PMOs are critical to their own success.

 

What's your experience? Please feel free to weigh in on this debate! I'm sure we all have a great deal to learn about making PMOs more "PM friendly".

 

Dave B.

Web 2.0, unlike SaaS or On Demand, is a term that defies easy definition.  A quick search of technology blogs and news sites reveals as much agreement as disagreement about the meaning of Web 2.0.  Just as the web it describes, the term has evolved since it was first coined to signify a second wave of web development following the bursting of the dot-com bubble in 2001.  It is variously used to describe web applications that use specific technologies (such as AJAX or RSS) or include specific functionality, especially related to social networking and collaboration (such as blogging, tagging and file sharing).  More generally, it is used to describe a product development mindset, with the web and associated software as a platform (a commodity!) that enables collaboration and the delivery of services (real value!).  And of course, there are those that simply regard it as yet another empty buzzword used to garner investor and analyst attention.

So what does Web 2.0 mean to eProject and our customers?  Not much, really.

Since our inception in 1997, eProject has been and continues to be focused on delivering web applications and services that provide real value to our customers by helping them solve business problems.  Our technology roadmap, like our product roadmap, is driven by customer need, not industry buzz.  If anything, the hype surrounding Web 2.0 is a validation of the eProject SaaS strategy and our position as a leading provider of OnDemand PPM.  By any measure of what it means to be a Web 2.0, eProject was Web 2.0 before there was Web 2.0.

Collaboration and Information Sharing? 
Starting with the first release of eProject Express, our core value proposition has been business collaboration.  Enabling teams to share and track information so that they may better execute on business initiatives.  In subsequent releases, this distribution of information was extended to portfolio managers and executives, putting key information into the hands of decision makers without requiring project managers to move data from one tool to another.  The upcoming release of PPM6 includes project requests and resource planning, extending the reach of information to steering committees and resource managers.  All in a single integrated, collaborative solution.

Wikis? Blogs? Knowledge management?  Expect eProject to continue to add collaborative, information sharing features that increase the productivity of our customers and their users.

Technology?
AJAX is not new, nor was it new when eProject Enterprise 5.0 introduced a powerful, cutting edge AJAX Gantt chart.  But AJAX made sense and allowed eProject to deliver on our vision of web application requiring no additional client software other than a web browser.  We will continue to use AJAX to improve the user experience and to bring the concept of OnDemand into the product itself--retrieving data when and as it's needed instead of reloading entire pages of content.

RSS? VoIP?  We are always evaluating new technologies and will leverage those that make sense to our customers and their needs.

A Service Platform for Integration?
eProject Enterprise 5.0 introduced Project Transit and the Business Services web service, that enabled our customers to integrate existing practices and processes into eProject and to define new processes.  In PPM6, we've extended our web services to support directory service integration.  In subsequent releases, we will be extending our web services to expose more functionality and to enhance our support for industry standards, such as WS-Security and WS-ReliableMessaging.

Businesses are increasingly turning to SaaS solutions from a variety of vendors and it is critical that such solutions adhere to principals of SOA (Service Oriented Architecture) and EDA (Event Driven Architecture).  More and more complex business processes will be created, spanning multiple systems.  As a result, implementations of BPM (Business Process Management) solutions, currently the purview of enterprises with large IT departments, will become more ubiquitous.  The eProject services platform will contine to evolve to meet the needs of ever more distributed architectures.