The Importance of Project Management Software

Have you ever wondered how important software is for managing projects? How much time does it save? How much it can help you in delivering a successful project? What parts of it are lifesavers and what parts can you live without?

Having these questions ourselves, our company has conducted a research with a subject “Project management on an enterprise level”, during the past month, supported by Seavus Project Planner and Seavus DropMind™. The main purpose of the research was to identify the needs and requirements of people who are faced with project challenges everyday.

The research has shown some very interesting results that we would like your input on.

Part I

First, let’s share the statistics about the respondents. The first part of the survey was dedicated to analyzing industry the companies operate in, company’ size, location and job title of the respondent.

From the responses provided, most respondents work in companies within Manufacturing (13.40%) and Consulting (11.34%) industries, directly followed by Business / Professional Services (8.25%), Construction / Home Improvement (8.25%) and Government / Military (7.22%). Other industries presented have less than 7 % of respondents.

Regarding the companies size, most respondents work in SME (24.74%) directly followed by companies with 1000-10000 employees (18.56%). However most of these companies have between 1 and 3 offices (51.55%).

The job title of the respondents is summarized in the graphic below:

We believe this reach provides an accurate sample of the PM market, and that the conclusions can be trusted.

Part II

Next part of the survey was connected to the actual usage of the project management software that is chosen within the responders’ company.

We wanted to explore the usage of the Microsoft® EPM within these companies and more or less we were surprised by the answers. It is interesting to see that large number of companies that have been using MS Project Standard are not using Microsoft® EPM and do not even consider implementing this solution within their companies.

However, it was also interesting to see the importance of different parts constituting the project management solutions for the people using Microsoft® EPM (or for those that are considering using it in the future) and for the people who haven’t been using it or are not considering using it in the future. We have divided the most important features in 4 categories: Project Management, Resource Management, Time Management and Collaboration. Follow up the appropriate responses in the tables below:

(The green colored cells are related to respondents who are or will be using Microsoft® EPM and the orange colored cells are related to people who are not or will not be using Microsoft® EPM).

As you can notice all of the features above are important and very important for the biggest number of the respondents, except for the wikis which both groups has indicated as not important feature. Moreover, almost 79% of respondents stated that it is very important or critical for them to track project progress. Assigning privileges/roles is valued with 3, (on a scale from 1 as useless and 5 as critically important), from almost 50% of the respondents and for all respondents is important to know that their project is on budget and on schedule.

Other interesting answers were given on questions such as where the respondents store important documents (.mpp files; general documents and project related documents). The answers were diverse, since this was an open question. However, some of the most frequent answers were: on the Server, SharePoint, Network, and File Server and it is more than obvious that people want to have their pm solution installed on the server in the company (89%) than to have it hosted (10.81%). Moreover, they prefer to install the solution from their own IT department (75.68%) than to have the installation from the solution provider (24.32%), but almost 57% of the respondents are ready to pay for installation and support from third party.

The answers on the question “How the teams update task progress?” were expected. 37.55% of the respondents stated that e-mail is used for updating task progress. Surprising 18.18% of respondents verbally update tasks and 15.58% use MS® Excel. Software programs were mentioned by a small number of people.

Same answers were given on the question “How do you share info about late tasks, risks, or general project related knowledge?” with 75.32% for e-mail, 48.05% verbally and 28.57% MS® Excel.

This survey provided many valuable answers, but as you can notice, there are some conflict areas. We encourage you to share your opinion on the results and moreover your experience in the field. Let’s create together the big picture of this survey.

Should You Equip the PMO with Netbooks?

Let me answer that right now…NO. However, are they bad? Again, NO. Now that I’ve gotten my feelings off my chest on this, let’s dive in a little further.

Don’t get me wrong, I wholeheartedly approve of netbooks. I’ve purchased two of them in the past four months. They’re great in the right situations and some of those can be PM-related.

First, I feel that there are some misperceptions with netbooks that most people have and need to overcome – I was included in this group at one time:

• The screen is too small. It’s not. It’s small, but unless you’re working heavily on graphics, the size is a plus rather than a minus. I’ve grown tired of the large, widescreen laptops. I’m much happier on my 13” Macbook than I ever was on my cumbersome 15.4” Gateway and I’ve used one of our home netbooks to surf, write a document, etc. and had no problems at all with it’s screen size. Granted, it’s of the 10” variety, not one of the 8” netbooks.
• The CD/DVD drive is critical. I can’t tell you when I last used a CD/DVD drive unless it was to load a CD into iTunes (which I almost never use anyway). I purchase software online and download so I know it’s possible to live without those drives. But, if you must have one, you can purchase an external one and some of the models at Costco actually come with the external drive included. The CD/DVD drive is no longer a necessity…it’s a ‘nice-to-have’ and an ‘almost-never-used’ extra.
• The processing power won’t be there. I don’t see it. I bought two of the the Asus Eee PC netbook. It has the Intel Atom processor which operates at 1.60 GHz and the netbook comes with 1 Gb of DDR2 RAM. Now, they aren’t being used on Photoshop, but for high school and college work and for low-end photo editing, writing, some video editing, etc. the netbooks have done everything we’ve asked of them.
• They are more fragile than a regular notebook. Again, not true or at least I don’t see it. In fact, because they are smaller and easier to carry around, dropping them or hitting on something as you walk by is far less likely. My 15 yr old daughter has gone through two phones in that time period by her netbook doesn’t have a scratch on it and she takes it everywhere.

So at this point, I seem to be a netbook proponent. And I guess I am. However, is it a good idea to equip your entire PMO workforce with netbooks and send them out into the world? I’m not likely to agree with that.

I think it may be a decent concept to have some around for checking out by PMs for travel or if your company has that much money to spend, give each PM one to make traveling easier. But I do not think the netbook is ready to be someone’s only work machine. It’s a good add-on if you have the money to spend, but it’s not ready to be a primary machine. I wouldn’t equip my whole family with netbooks as a replacement for all laptops (and I’d NEVER give up my Macbook), so I know I would not condone making this standard fare for all of your PMO’s workforce.

The Project Procurement Plan

Here is another template who’s usability really depends upon the given project and the customer.  This one is the Project Procurement Plan.  It’s great for larger projects and for government projects and it is designed to be produced at the beginning of the project along with documents like the Risk Management Plan and the Project Communication Plan.

The idea is that you lay out the formal process of how you will go about procuring things for the project throughout the engagement.  In this document, you identify formal processes for vendor selection, customer/vendor responsibilities and contact info, how the selected vendor will be managed as the procurement is taking place and who’s responsibility that will be, etc.  Laying these formal processes out in advance will definitely help the engagement move along more smoothly and will help you to address this issues as the arise.

PROJECT PROCUREMENT PLAN

[Save file name as: client name PROCUREMENT PLAN yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

PROCUREMENT DEFINITION

Describe, in specific terms, what items will be procured and under what conditions.

CONTRACT RESPONSIBILITY

Provide list of project stakeholders who are authorized to enter into contract agreements of purchase for the Project.

VENDOR SELECTION

Describe what steps the project team will take to select a vendor (e.g. RFI, RFP)

DECISION CRITERIA

Describe any known risks which will need to be addressed with the project statement of work.

CONTRACT TYPE

Document which types of contracts will be used and what actions need to be taken to initiate procurement.

CONTRACT STANDARDS

Provide the standards for documentation that will need to be initiated and maintained for each contract.

VENDOR MANAGEMENT

Describe what steps the project team will take to ensure that the vendor provides all of the products and/or services (and only the products and/or services) that were agreed upon, and that appropriate levels of quality are maintained..

ASSUMPTIONS

Describe the initial assumptions under which the project will be to perform.

CONTRAINTS

Describe the scope/cost/ time/resource constraints under which the project will be to perform.

IDENTIFIED RISKS

Describe any known risks which will need to be addressed.

APPROVAL

IN WITNESS WHEREOF, the parties have agreed to the Procurement Plan on the date or dates indicated below.

CLIENT APPROVAL

________________________________

Client Signature

VENDOR APPROVAL

_________________________________

Vendor Signature

The Project Resource Request

Here is yet another template that I am digging out of my archives to provide here.  As you can easily guess, this document is designed for requesting resources at the beginning of your project based on information in your statement of work (SOW) and the estimates of resource requirements that either you or Sales put together in the pre-engagement process.  It is also helpful for requesting additional resources during the project.

How useful this is to anyone depends on the organization they work in.  If you have a mature PMO with processes in place, then I would guess that you already have a standard form or spreadsheet to use to request resource for your project.  However, if you’re one of just a few PMs or personnel acting in a PM role in your organization or you’re in the process of building some PM processes for a newer organization or even setting up a new PMO, then any template may be better than nothing.

As with all of these documents, if you want the original Word doc file, just email me if you think this will be useful or helpful.  And please, provide your own example if you wish.  We’re looking to learn and share information so I’m happy to use and post whatever you would like to provide to the readers of PM Tips.

PROJECT RESOURCE REQUEST

[Save file name as: client name RESOURCE REQUEST yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

WORK DESCRIPTION AND ROLE

Describe the work to be performed on the project by the resource(s) and what role the individual(s) will play on the project team.

DESIRED SKILLS

Describe the technical, business or professional skills needed by the resource(s) to successfully meet the needs of the project.

DELIVERABLES

Describe the deliverables the resource(s) will be responsible to complete as a result of their work on the project.

DATES REQUESTED

Starting: mm/dd/yyyy Ending: mm/dd/yyyy

HOURS OR % FTE

Provide the estimated number of hours or the percent of time the individual(s) will be need to be allocated to work on the project.

WORK LOCATION

Describe all of the locations the resource(s) will be expected to be located – if multiple locations, provide dates as they are know at the time of the request.

REPORTING STRUCTURE

Describe the reporting structure for the project and how the individual(s) will be expected to operate within this structure.

Agile Software Development in a Standard Project Management Methodology

I’m sorry everyone, but I’m going to do it again. I’ve learned a lot from the Agile vs. Standard software development process discussion that is still going on based on two other articles (“Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More Thoughts”).

In very early articles I discussed the general hybrid project management process I use to manage projects. In practice, it incorporates these phases:

• Phase 1 – Project Kickoff
• Phase 2 – Exploration
• Phase 3 – Design
• Phase 4 – Development
• Phase 5 – Testing
• Phase 6 – Training
• Phase 7 – Deployment
• Phase 8 – Post-Deployment

Process Flexibility

I realize that all project management needs to be flexible to some degree. We need standard practices and templates in place to follow or we are destined to failure. We need some flexibility because not all projects and customers and resources are the same. But not too much flexibility because structure and order lends to repeatable processes and practices and usually leads to greater success and a better understanding of how that success came about.

So the agile question this time around is this…can an agile development process be fit into a standard project management methodology? Or does the entire project management methodology and process for the project thus become agile as well?

Project Management in an Agile Environment

Design, Development and Testing phases would be modified to accommodate the rapid and iterative development, testing, and rollout process that is dictated by agile development methods. That’s understood. But are the project management processes used on standard or waterfall development projects usable for an agile development process or does the entire project management process need to conform to the agile development process?

I’m pretty sure I’m educated enough on this to understand how this needs to go, but I welcome the on-going discussions here because it is certainly further educating me, and I know it is also educating and interesting others who may or may not be aware of agile development and project management processes.

One of my colleagues/readers on here noted that good project management must always be agile because requirements are never firm…they are always changing to some degree. Even I realize that even though I tried to present the ‘perfect’ requirements scenario in the two articles mentioned above.

He also stated that “outcomes” need to be emphasized over “output”. A very good point and observation. A standard project management process does a nice job of emphasizing output – each phase has outputs and deliverables that need to be reviewed and approved in order to move on to the next phase. Whereas an agile process emphasizes the outcomes – successful packets of work that build on each other.

I look forward to the discussion to follow – it will make me a more flexible and educated project manager…and I’m always interested in learning.