We have all heard on at least one occasion that we should strive for consensus in the decision-making process. This sounds simple enough, but is it something we should really aim for?  According to Wikipedia, “Consensus is the community resolution when opposing parties set aside their differences and agree on a statement that is agreeable to all, even if only barely.”  Doesn’t sounds quite as positive a goal now does it?

Why is consensus good?

Consensus is actually a good thing from an execution standpoint:

• When you have a team that works together to reach a decision, you have a team that is more likely to stand behind the decision.
• Since they have become a proponent of the decision, they will be more likely to voice their support to outsiders
• They will work to ensure that the decision/goal is achieved. This is useful when you are incrementally improving a process or product as they will be the team that has influence over the outcome.

Why is consensus bad?

On the flip side of the execution piece, consensus is bad from an innovation standpoint:

• Dynamics of groups often force consensus because dynamic/dominant characters tend to push everyone to their side and peer-pressure forces the stragglers to join the majority
• This limits the number of inputs which can reduce the chance of new ideas
• Innovation rarely comes from consensus because people are not likely to agree on something revolutionary and novel
• In order to gain consensus you often have to give up on some of the more audacious aspects of the idea

Conclusion

In conclusion, you need to determine your goals of a project when deciding how hard to press for consensus. If you are working to improve existing processes/products then consensus can be a fine goal.

However, if you are trying to shake things up and change the world, then consensus will get in the way of your goals. Do you think Steve Jobs cared about consensus? No, he cared about making something amazing.

• Some people may think that the person is bringing relevant information to the table.
• Others may think that the person is just trying to make themselves seem important.
• Others may think “that will never work here”

The truth is that everyone leverages past knowledge/experience to conduct their current job. If this was not the case, managers would not care about professional experience. Hiring people who have performed similar jobs helps with the on-boarding process and execution of a job.

However, where we need to be careful is assuming what worked at one company will work at the current one. This is due to the fact that companies are very different from each other:

• Goals – each company wants to maximize profits, but how they wish to achieve this varies. Some want to increase the amount of profit per project. Others want to increase the number of projects with each client. The goal of the company (and each project) may vary from company to company and applying preconceived notions can be problematic.
• Internal processes – even if your previous company had the same goals as your current job, the processes that are used to get there may vary. Company formal (Policies, SOPs, and Work Instructions) and informal processes are likely to vary from company to company. Unless you take the time to learn the processes of your current company you are likely to run afoul of them.
• Stakeholders – over time at your previous jobs you became familiar with your stakeholders and learned what they required of you. At a new job you need to take time to do the same thing. Each stakeholder (internal and external) needs/wants different things. Assuming they all want the same will lead to project and professional stumbles.

Using previous experiences will help you prepare for a new job, but when you join a firm you must be careful to take the time to understand how/why your current company operates. Focus on the goals, processes, and stakeholders of the new job. Taking the time to understand how your current job works will improve how you operate and may also help prevent any missteps.

The tune has changed

In the early years of the project management discipline, project managers were the central role of the project. They would be the one team members would go to with updates and the stakeholders would go to for answers. Technology is changing this.

-Prior to widespread adoption of project management computer programs, project managers would often be the source of information (time lines, cost, etc.) to stakeholders. Now, project stakeholders can often access a program or file to see the status of the project.

-Prior to these same programs, project managers would have to communicate with the project team members to get updates on tasks and issues in order to manage the project. With technology, the team can log onto a system and update their tasks without having to talk to the PM.

These two factors make many companies view project managers as little more than managers of the tool and thus trivialize the role. For this reason, project managers have to demonstrate the value they bring to the project.

Don’t be a backup singer

To overcome this viewpoint of the field of project management, project managers have to demonstrate the value they bring to the project. Project managers are not simply administrators of the project, rather they are leading/managing the project. This distinction needs to be emphasized and demonstrated to managers and companies.

-When it comes to providing project updates to stakeholders, don’t just show the metrics but rather relate the metrics and project to business drivers and outside influences. Knowing that a project is behind schedule, but is still going to finish prior to the true deadline is much more relevant than knowing the project is behind in terms of earned value.

-Team members are now becoming viewed as a more valuable commodity within the project (no longer simple cogs) and this is great for the projects. PMs need to make sure they work for and with the team to facilitate success. Focus on developing the team members within the course of the project and you will be delivering continued value to your firm/clients.

These are just two ways you can help to ensure that your stakeholders and management team continue to view you (and PMs in general) as a valuable commodity that should be respected.

Let your voice be heard

How are you making sure that the role/position of PM does not disappear in your industry or company? Let us know the steps you are following to improve the relevance of the job and reducing the trivialization by technology.

I think the main components needed to put people in a position to succeed are:

1. A clear vision
2. A stable and mature framework
3. Access to the proper tools

Provide a clear vision

Company Vision

• The team needs to know why the company is in business. Is the company just trying to make money or is it trying to improve the world (or industry)?
• The team needs to know where the company is going. What does the company look like 5 weeks, 5 months, 5 years from now?

Team vision

• The team needs to know what they are working on.
• The team needs to know why they are working towards a certain goal.

Individual vision

• Team members need to know what type of tasks they are going to be asked to do on the project.
• Team members need to know what they will learn during the project.
• Team members need to know what the future has in store for them professionally.

Provide the proper framework

Organizational structure

• The team needs to know how they fit into the puzzle.
• What is the reporting structure?
• Who do I go to with questions?
• Who tells me what to work on?

Project management methodology

• Methodology choice is unimportant! Choose a methodology and then follow it.
• Educate the team on the methodology you are using for the project.

Provide the proper tools

Technical resources

• Make sure the team has adequate technical resources:
• Computers
• Software
• Materials
• Team/meeting space
• Snacks…all team members appreciate food

Human resources

• Make sure you staff the team adequately
• Enough resources
• Qualified resources
• Motivated resources
• Make sure you develop the team via training and personal development initiatives

Following the above steps may not guarantee project success, but not following them certainly can doom a project. When the team knows that you are committed to them and the project, they are more likely to return that commitment in kind. Remember, you are all in this together, and you depend on them just as they depend on you. Do what you can to put your people in a position to succeed and you are more likely to succeed yourself.

My company recently completed our most recent iteration planning session. It was an eye-opening experience for most of our team had not been part of an iteration planning session before. Below is a checklist that teams can use to help ensure that their iteration planning meeting is successful.

Before the session:

• Product backlog has been finalized
  • All backlog items have been assigned a stack rank by the Product Owner
  • All backlog items have been assigned their story points by the Project Team
• Project Team has been prepped
  • Team has been trained on basic Scrum processes/roles
• Situation has been analyzed
  • Outside factors have been reviewed and impact on team has been documented
  • Project team member capacity has been evaluated/documented
    • # of hours per day for each worker
    • # of days each worker will be available during the iteration
• Meeting logistics have been finalized
  • Meeting location has been booked for the entire day
  • Project team has been made available for the entire day
  • Lunch has been ordered

During the session:

• Session was initiated
  • Welcome team to the meeting
  • Review iteration planning process
• Backlog is triaged
  • Tasks are defined for each user story
    • Task duration estimates are documented
    • Task owners are documented
• Agreement is reached
  • Project team and product owner agree on the plan of attack
• Meeting is evaluated
  • What went well and what could be improved

After the session:

• Iteration tracking system is set up
  • Allow tracking of all iteration tasks
• Daily scrum meetings are set up

Following the steps above should help make your iteration planning meeting your most successful yet. Do you have any other tasks/items that you feel contribute to the success of your iteration planning meeting?

Far more often, the PM who keeps trying to juggle more and more projects is bound to fail and wind up with projects on the floor. This is because all of us, no matter how skilled, have a pre-defined capacity.

This capacity varies from person to person, but no one can manage unlimited project or priorities. We have the ability to start many projects and get the ball rolling, but once the project progresses the time and intellectual commitment dramatically increases.

As each project requires more and more personal resources, PMs try to find ways to compensate.
These include:

• Delegating more and more work which they should be doing
• Taking shortcuts in terms of documentation or communication
• Pushing out deadlines

None of these solutions is ideal or, in many times, acceptable. PMs need to be able to focus adequate internal resources on every project they are managing.

Hopefully your company performs resource planning/leveling and never puts you in a position where you are over-allocated, but in talking with other PMS and reading other blogs I seem to get the distinct impression that many of you feel like you have too many projects.

So what is a PM to do? Increase communication!

With project stakeholders – Ensure that you keep all stakeholders informed of the status of your projects at all times. If things are running behind schedule let them know. If you are unable to meet a commitment let them know. If you need more time for a deliverable, ask for it. No stakeholder likes to hear about project issues, but they are much more upset if you hide the issues from them.

With your management – If you have conflicting priorities let them know. If you are unsure how to proceed let them know. Most importantly, don’t hesitate to ask for help. Saying you need help is not a sign of weakness. Rather, admitting that you are not invincible is one of the bravest things you can do because it shows that you understand your limitations.

These ideas are not silver bullets that will solve all project problems, but hopefully they can help you with some of your project issues. If you have other ways you handle situations when you feel you are losing control, please add a comment to other readers can benefit from your experience.

Project managers are evaluated not when the dealer is shuffling, but rather when the project is over and all the cards have been played. This means that you must work your hardest throughout the entire life of the project. I have talked to some PMs and their passion is in creating the project schedule or gathering the stakeholders together in the beginning of the project. These tasks are important, but they ultimately do not decide the fate of the project.

The project outcome is determined by the consistent and continued effort of the PM and the project team. The overall execution is what matters during the project, not the ideas behind the project or the preliminary groundwork that is laid. As such, a project manager should dedicate most of their time to ensuring that the execution phase of the project is successful.

I know that many PMs state that the initiation phase is the bulk of the work and that it is then smooth sailing until the completion of the project. However, it is far too easy to get derailed if you do not dedicate adequate vigilance to monitoring the project. Do not overlook the details of the project or you will be reminded of them during the uncomfortable lessons learned meeting that folllows.

If you commit to working the plan during the entire project and dedicating energy and effort to control and monitoring, then you will have a greater chance of project and career success.

1) Lack of management buy-in

In order for scrum to succeed within your organization you need to have the support of management. Scrum processes and artifacts are quite different from what most managers/executives are familiar with. If your management team is not comfortable with the new process then they are likely to become an impediment (albeit an unwitting one).

Solution: If you want your management to be onboard with scrum and even champion it to other executives; you need to provide them with ammunition. In this case, the ammunition is knowledge; knowledge of the scrum processes and examples of companies which have successfully used scrum to improve their project success rate.

2) Not empowering the team

Scrum works only when the project team is empowered to use their insight and experience to make the appropriate decisions. Treating the team like a bunch of children (like many project managers do) does not motivate the team to perform to their best ability. You need your team to work at 100% and use their creativity and passion to push the project to completion.

Solution: As the scrum master you need to focus on serving the team rather than leading them. Your primary mission is to make sure the team has what they need to succeed. As the old saying goes “Give a man a fish…” well, you know the rest.

3) Viewing Scrum as a light-weight methodology

Many teams jump to Scrum because they feel that it is an approach to a project that just lets them code/build/etc. and not have to worry about processes or documentation. The teams that adopt Scrum because of this misconception are doomed to fail in their adoption of Scrum and in the execution of their projects.

Solution: Set realistic expectations that Scrum is just as rigorous as traditional methodologies. While traditional methods require a great amount of documentation, they usually offset this by reducing the amount of time the developers are in meetings and the amount of communication the team is required to create. Scrum on the other hand may reduce the initial documentation expectations, but it requires the team to be available and increase the frequency and immediacy of communication. This can be a big change to developers who sometimes camp in front of their monitor for a day or two at a time and do not talk to other team members.

Conclusion

While the challenges above are legitimate ones, they are by no means insurmountable. I have provided some basic ways you can counter the bad habits and situations you may encounter. Scrum is a powerful tool for creating change within an organization/project and the effort to implement it is well worth it.

Interface

• Ribbon
  

  
  If you have MS Office 2007+ installed, you are used to the ribbon interface which replaces the menu bar. This interface is more efficient and lets you perform common tasks quicker. MS Project 2010 has incorporated the ribbon and I have found that they selected the right button/features to highlight. You can now create/update your schedule quicker without having to jump into sub-menus. And as we all know, the less time you can spend updating your schedule, the more time you can use to actually manage the project.
  

• Data Entry/Manipulation Improvements
  Microsoft has also added numerous enhancements which allow you to focus on creating/editing the schedule and not worry about how to format the document/plan.
  
  • Auto-completion of field values allows you to select from previously entered information when filling out a field. This is especially useful when entering the resource for tasks.
    
  • Enhanced filtering of fields which allows you to analyze the data without having to export to Excel. 

  • Enhanced formatting options which include color/format as well as automatic wrapping of text within fields.
    turns into
    

Functions

• Timeline – quick view of project overview
  
  • Reach your audience with new impact by quickly copying the timeline into an email, presentation, or any other document with formatting retained. 

• Manual vs Automatic scheduling 

  • Allows you to decide whether you want project to automatically figure dates for tasks or if you want to manually decide/enter them
    
• Team Planner 

  • Simply drag-and-drop to effectively plan tasks and optimize resources for your entire team and project.
    
    • Quickly identify unassigned or unscheduled tasks to proactively solve problems.
      
    • Simply hover over tasks to instantly view task-level details to plan with ease.
      
    • Be visually alerted to potential problems, choose to manually level resources as you work.
      
• Save as PDF
  
  • Many PMs have been waiting a long time for the ability to save MS Project files as .pdf files. Well, the wait is finally over.
    

Compatibility

• SharePoint 2010 Integration
  

  
  The ability to publish your project schedule to sync with a SharePoint Task List is important because it allows everyone on your team to have access to the schedule/task list without having to install MS Project on their computer.
  

  You can also have your team update their tasks online and then pull those updates back into your project file.

I am sure there are many other features to MS Project 2010 that you use on a regular basis. I would love to hear which features you think are most useful in your day-to-day life as a PM.

Low-fidelity – a low-fidelity prototype is a rough graphical representation of the system. It does not contain functionality, but rather aims to get feedback on the general design/look and feel.

• Pen and Paper – has the benefits of being cheap and having a very low learning curve. Hard to version drafts without manually creating new papers.
• Balsamiq Mockups – software tool that allows you to create mock-ups/prototypes very easily. Can export output to image files for distribution.

Medium-Fidelity – a medium-fidelity prototype is used to refine the look and feel of the system or define high-level interactions.

• Photoshop - using Photoshop allows you to clearly define the final layout and look of the system. Users will get to see exactly how the system will look and can verify it matches their needs
• Flairbuilder - allows you to create interactive prototypes that can convey high-level workflow/capability.

High-Fidelity – a high-fidelity prototype is used to gather feedback on the usability/workflow of a tool. These prototypes take longer to create, but can be used with end-users to ensure that the product works as needed.

• Dreamweaver (or other HTML editors) – creating a HTML-based prototype allows you to build a prototype that looks and acts in a similar manner to the final product. Back-end code is not included, but the interface/experience should match.