Part 2: If projects are like gasoline – Project Management Tools for Small Projects

May 4, 2012 — Bruce McGraw

Last week I talked about gasoline octane ratings as a metaphor for the relative performance and capability required of project management tools. According to Wikipedia, the octane rating is a standard measure of the performance of motor or aviation fuel. The higher the octane number –the higher the performance. Or, in the case of PM tools, large complex projects need high-octane, specialized tools, while small projects get by just fine exploiting the capabilities of the tools you commonly have around the work site.

Small projects (or Unleaded projects!) usually have characteristics of short time frames and minimal staff.  They occur within a short time frame — often less than six months and do not require nor have a full-time project manager. Several people may work on the project, but few if any, are assigned full-time. However, even small projects need to document their charter and scope, organize a task list and schedule and report on their status or accomplishments/issues.

In my experience, Microsoft Office applications, including Excel, PowerPoint, Word and Outlook, provide enough of the octane that a small project needs. Here are some examples of project management using Microsoft Office applications:

Task detail and scheduling
The workhorse tool for managing small projects is Microsoft Excel – in surveys that my company has conducted, MS Excel was the number 1 project management tool used by organizations. In fact many medium or large projects use Excel for some of their PM duties. I like the ability of Excel to quickly generate a task list, which can include a brief description, start and stop times and assignments. The tasks and time frame can then help build a simple Gantt chart. All of the charts produced in Excel, as well as the task detail, can be copied into Microsoft PowerPoint for presentations or Microsoft Word for reports.  The team can use email to distribute the excel sheet for updates.

Here is an example of an Excel project tool:
Status Reports

Here is another example of using Excel as a status report:

Cost Analysis

Spreadsheets, like Excel, had their roots as an accounting or number management tool (for some of us we remember using a program called VisiCalc!). So, it is no surprise that it provides a great deal of capability to manipulate cost figures, such as creating planned versus actual cost comparison.

And here are some ideas for a One Page

Summary Report using MS PowerPoint:

Project managers are not limited to simple things either, they can create a complete project workbook in Excel using the tab feature for various project documents, such as the charter, budget, risks and issues, action items, WBS and decision logs.

Also email, such as Microsoft Outlook and Exchange Server, serves as the primary formal communication tool for setting up meetings and sharing information both inside and outside the team. Within the team, Outlook can also be used to share information. However, the team will also benefit from communication using sticky notes, task boards and face-to-face discussions using other tools like GotoMeeting, WebEX or Live Meeting.

OK- so let’s look at the pros and cons of using Office tools for managing projects:

Pros of Using Microsoft Office for Project Management

  1. Most users already know how to use Word, Excel and PowerPoint – not much training needed
  2. Low initial cost – in fact most organizations already have these tools
  3. Tools and work products can be easily modified – the work products can be branded and modified to fit the project
  4. Many project management templates are available – if you look online, you will find hundreds of templates for these office tools

Cons of Microsoft Office for Project Management

  1. Staff/users have varying levels of skill and proficiency – even though everyone may have these tools, many people have never had to use them for advanced functions like making a project schedule or status report
  2. Data is not real time – have to send the file around and wait for distribution
  3. Version control is problematic – I hate the game of multiple people editing a file at the same time and then figuring out which one is the most recent
  4. Updates are more labor intensive – if you try to control changes to the project with one person (eliminating the version control issue) then you create a bottleneck

So, in summary, if you are on a team tradition project or agile, you can utilize standard office tools to help the teams manage the project without having to invest in expensive tools and technology.

If you have comments or thoughts about using Microsoft Office or other tools for small projects, please share.

Part 3 of our series will cover the “Standard” or regular projects and tools.

Posted in General Project Management, Project Management, Tools. Tags: , , , , . 5 Comments »

Dealing with a micromanaging boss or client

March 30, 2012 — Bruce McGraw

OK – How many of you have had to deal with a boss or client who is what we call a “micromanager”?  There are successful techniques that you can apply to help deal with a boss/client that micromanages your project. First though, it helps to understand where the micromanager is coming from and what problems he or she is trying to avoid.

Behaviors of a micromanager

Micromanagers are into control. Micromanagers are afraid to delegate authority or responsibility. They want to be apprised of even the smallest details about the project. And, they need that information updated constantly (Many would prefer telepathic real time updates!). Micromanagers often want to make ALL project decisions — from the important ones, such as staffing, to the minor ones, like the placement of the white board. Their constant need for data and their tendency to require “all decisions go through them for approval” slows the team’s progress — not to mention driving you, the PM, a bit batty.

During the execution of a project, the micromanager may not limit their interaction to requests for information. They may also try to tell team members how to do their jobs (even if they have never done the job). Be aware that on the rare occassion when the micromanager appears to be delegating authority and responsibility, they are likely to take back control at the first sign of trouble.

Motivations of a micromanager

I am not saying that I agree with micromanagers, but understanding what can motivate or drive them to this behavior is the first step in dealing effectively with them. Here are some of the common motivations:

  • Micromanagement may be the only kind of management they know how to do
  • They may be insecure in their position or in their knowledge
  • They genuinely believe that the project will not succeed without their direct and constant involvement
  • Because they do not feel competent to deal with complex issues, they choose to deal with small, trivial ones where they do feel competent
  • Maybe his or her boss is micromanaging them, and you know the saying about stuff rolling downhill….

Consequences of micromanagement practices

If you have a micromanager then you will have probably experienced or observed the following:

  • Team members stop trying to improve processes and results
  • Project do not succeed as well as they might have if everyone applied more of their knowledge and experience
  • Project managers (and other project members) fail to learn lessons that help them mature as PM professionals
  • Leadership is not developed (see Project Leadership Requires Sharing Responsibility)
  • High rate of employee loss — especially the bright, talented and potential future managers
  • Increase in stress, anxiety and anger for everyone involved

Working effectively with a micromanager

Well I don’t have any magic bullets, but here are some tips you can try.

As justified as your frustration and anger may be when you have to work under a micromanager, you need to take a deep breath and make the best of the situation. Then, you need to take some actions to try to counter the effects of this behavior on the project and the team.

Anticipation of the needs of the micromanager for authority and information should be dealt with preemptively. For example, when given a task, find out as many details as possible about the micromanager’s expectations. Listen carefully and feedback your understanding of the task. Asking detailed questions may limit the number of “bring me a rock” exercises you have to go through.

Keep the lines of communication open with the micromanager – yes I know how painful this can be. You may be able to build a trusting relationship over time that allows you to provide feedback on the deleterious effect of his or her management style. At worst, you will at least be able to talk with them about how it negatively impacts the project.

Provide the level of detail and frequency of project information they ask for, but add information on why and how. You may be helping to train the micromanager at the same time increasing their trust in you. Take the initiative to set up meetings and phone calls before they ask.

Give credit to the micromanager when it is due and reward them verbally when they stop micromanaging for a minute.

Don’t let them “push your buttons”.  Keep your cool and remember that you are doing the job and keep reminding them that you can handle the tasks.

So have you had encounters like this?  What tricks and techniques have you used?

Posted in Best Practice, General Project Management, Leadership, management, pm, Project Management. Tags: , , , , , , , . 5 Comments »

Enterprise Project Management (EPM) and Project Portfolio Management (PPM) tools – the Rest of the Story

March 24, 2012 — Bruce McGraw

This year I have been asked about EPM / PPM solutions, as opposed to project level tools, more often than in the past – at conferences, after presentations and in the coffee shops. Senior managers and CIOs want tools that can work organization-wide to improve performance, support decision making and to manage risks. Maybe this new level of interest is caused by worries about the whispers of economic recovery or comes from the frustration of trying to integrate disparate pieces of project data for the last few years; I am not sure. What I know is that managers today want information that is broader, deeper and richer than they have had in the past.

Never wanting to miss a sales opportunity, many vendors of process or project management software are portraying their products as being up to the challenge of providing enterprise process management. Maybe. But, caveat emptor folks.

What is Enterprise Project Management?

OK – before I start spouting off acronyms, how about a few definitions:

  • Enterprise Project Management (EPM) – to quote Paul Dinsmore, “Enterprise Project Management is based on the principle that prosperity depends on adding value to business, and that value is added by systematically implementing new projects of all types, across the organization.”
  • Project Portfolio Management (PPM) – is the practice of managing an organization’s or enterprise’s projects as a visible collection (or inventory), combined with a process which ensures that the projects in the collection contribute directly to the organization’s goals (from BKC).

Using these definitions, enterprise represents the aggregate of activity across multiple projects and departments. In fact, I submit the EPM is more about process than technology and this is why throwing a tool at projects without focusing on processes is not going to improve anything!  Although information on task status, budget, schedule, documentation and resources is available for individual projects within an EPM tool suite, the EPM’s power comes from the ability to retrieve and aggregate information across all projects easily.  According to Deborah Nightingale of MIT presenting the “Principles of Enterprise Systems” at the Second International Symposium on Engineering Systems in 2009, enterprise project management facilitates the following:

  • Understanding status relative to strategic goals, vision and direction of the enterprise
  • Meeting information needs of the enterprise
  • Representing organizational structure of the enterprise, including boundaries between individuals, teams and departments
  • Collecting knowledge, capabilities, and intellectual property resident in the enterprise
  • Producing products and providing services and product support efficiently and effectively
  • Creating greater value for stakeholders

There are some basic capabilities I believe should be in any EPM/PPM software toolsuite:

  • Schedule Management – Gantt chart, scheduling engine, etc.
  • Resource Management – must have a global (i.e., single) resource pool and allow assignments to generic and real resources. Must also allow for progress tracking and reporting either by time or work complete.
  • Governance – must allow for roles and rules on how to approve and view information
  • Collaboration – should provide for an easy to use (hopefully, web based) mechanism for content management and storing of shared artifacts.
  • Reporting – tailored reports, dashboards, and general business intelligence to look at the project and program data in many ways.
  • Status – this may be similar to reporting, but the tools should allow for good communication and status updates with both quantitative and qualitative information

This is not an exhaustive list, but a good basic set of features that should be provided by EPM tools.  You may have your own list or use someone else’s, like the one on ProjectManageSoft’s website.

Capabilities of Enterprise Project Management Software

I believe that EPM and PPM applications must support individual projects and programs, as well as the larger enterprise. That means I want an EPM/PPM tool suite that allows “cradle to grave” tracking for projects — from selecting, planning, and scheduling, to status tracking, sharing, resource management and storing project artifacts. Project and program managers should be able to easily view information by portfolio, project, work site and resources. They should also be able to compare task schedules across multiple projects and for individuals. (I call this accountability.)

EPM applications should provide:

  • easy interface through corporate portals and intranets using a familiar browser interface
  • portfolio analysis and reports with visibility into ALL projects, programs or groups of projects
  • a central resource pool (so you can see ALL work for a resource – both people and generics)
  • managed, secure real-time access to project artifacts – like process diagrams and documents stored in a central repository
  • support for authorization or permission to access project related information and artifacts
  • “near real-time data” and historical data analysis and update notifications
  • easy integration with existing spreadsheets, word processing and desktop applications, like a PDF program
  • value to individuals and teams, such as what am I assigned to, how do I update progress, calendars, document libraries, and collaborative tools

 

The Rest of the Story

Purchasing an EPM or PPM application suite is not cheap — whether you choose Clarity, Microsoft Project Server, Primavera, PlanView or one of the other 50 less well known tool suites that claim to support EPM and/or PPM. And, purchasing the software is the beginning of having an EPM system, is not the end – you still have to implement it and support it.

Software tools that provide the power of a true EPM system and processes should be set up to integrate with your organization’s existing hardware and software. For most offices that means a tight integration with Microsoft Office. It could also mean sharing data with your finance or HR systems.  The applications must be tailored to your organization and your needs. This means you should only select an experienced professional consulting firm with in-depth knowledge of the tool, project management and business processes.

One other key part of implementing an EPM/PPM is that your staff requires training in using the tools or your organization will not gain the desired benefits.

Last, but not least, you should have a support plan in place.  In large installations, you will also need on-site support and maintenance that can be provided by direct staff or on contract.  Smaller implementations and organizations should have either a part time admin or support.  These complex applications do not run themselves.  And don’t make the mistake of “our IT guys can handle this.”  I have seen many good implementations fail because the IT staff is not experienced nor equipped to provide support for an EPM tool suite.

So is your organization planning to implement an EPM or PPM solution this year?  I would love to hear your fears and experiences on the subject.

One last thought – “A fool with a tool, is still a fool!”

Posted in EPM, General Project Management, management, Project Management, project management office, Technology, Tools. Tags: , , , , , , , . Leave a Comment »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 393 other followers