May 2010 Survey Results: Equipping the Project Manager

The results are in for the May PM survey on equipping the project manager.  The response rate was very good – many thanks to our readers who responded because without you there would be no survey and no fun follow-up analysis.

In terms of surprises, in my opinion there were four key surprises that I will describe in my run down of the results below…

Formal PM Methodology

Here’s the first surprise: only 53% of the survey responders indicated that their organization followed a specific project life cycle or project management methodology.  That means that 47% are basically ‘winging it.’  While that’s ok on occasion, it’s very difficult to realize long term organizational and project success without some sort of consistent, repeatable process in place.  Nearly half of our survey responders don’t have that and that’s concerning.

PM Software

No big surprise here … 58% use Microsoft Project as their primary tool for managing projects.  What was surprising is that a full 26% are not given any specific tool to use when managing projects.  Back to the ‘winging it’ concept… not good.  11% indicated that they utilized a web-based PM tool and 5% indicated that they use some desktop tool other than MS Project to schedule and manage projects.

Read more »

If There is No Project Schedule and No End Date, Is it a Project?

Have you ever had one of these handed to you?  Basically, it starts out as what seems like a task, and then grows into a project after you’re already knee deep in it?  I’m guessing many of us have – I know I have.  I’m going to look at my mistakes on this ‘project’ and would love to hear your feedback.  Since this was more than 10 years ago, I can safely say that I learned my lesson and thankfully history has not repeated itself.  Oh, and it did end fairly successfully, but not without a decent amount of pain.

I was working for a major engineering and aviation company running projects primarily for internal customers and primarily web-based projects when I was handed something like this.  The organization had recently sold of an entire business unit to an external company and there were lots of issues surrounding the transition of remaining files, environmental date, proprietary drawings, etc.  My first problem was that I was told it was ‘x’ amount of data that still needed to be transitioned and I believed them.  One more thing I should mention – there was much contention over this whole process to the point that the purchasing organization was withholding $250k of the sale till after the completion of the entire transition.  Oh, and I was asked to get this done as soon as possible.  Not a date, just a concept.

Mistake #1 – Assuming too much

I started the project out by assuming too much.  I took what information I was given, assumed it was all correct, and ran with it.  As a project manager, the first thing I should have done – and the first thing I would do now – was to ask the tougher questions internally before ever going to the customer (here the customer means the external company that purchased the internal business unit).

• I should have asked more information about the legal issues surrounding the transition and data
• I should have asked for and received an end target date up front (I did later get a fiscal year end date as the target for getting the $250k paid – which was the following September 30^th date.  In all the project ended up lasting a year and I don’t think any of us thought it would go that long.  Bad assumption and one that lead to me not even creating a project schedule.  Very bad idea … and one of the reasons that the project lasted for a year.

Read more »

Final Thoughts on Requirement Prioritization

Your first priority in the requirement prioritization may be selling the stakeholders on the concept of prioritizing requirements before design start.  This isn’t an easy task.  As we discussed, a customer stakeholder is likely to react with the notion that you’re actually trying to eliminate requirements.  You have to convince them that this is not the case.

Once the stakeholders agree to prioritizing requirements, you will guide the stakeholders through the prioritization process.  Then, you will incorporate the results into the project or the product development schedules and budgets.  You must enforce the priorities throughout the development process.

As development progresses, you will identify situations that trigger use of the priorities.  These situations may include: impending resource shortages, changes in external constraints or expectations, and conflicts.  You must ensure that the priorities rule the outcome.

Requirement prioritization early in development helps a manager control project risk and change.  Knowing requirement priorities focuses a product or project development team and guides intelligent choices for phasing in product features over time.  It prevents the “bailing” that so often occurs just before delivery, in which partially implemented requirements are thrown overboard in a frantic effort to save dwindling resources for finishing the critical components.  Above all, it’s one more communication channel between customers and developers.

Read more »

How the IRCTC used knowledge management to its benefit

In recent years, globally competitive companies have discovered the importance of an organization-wide knowledge management system (KMS).

KMS provides employees with instant access to knowledge gained throughout the organization, thereby enhancing business effectiveness. From being a hygiene factor, KMS has now evolved into a “must-have” component for customer-facing units or departments. For organizations that are spread across the globe, this is a necessity.

Customers contact the firm at various touch points, i.e. physical office or branch, the telephone and internet access 24×7. They expect instant resolution for a bulk of their queries, if not all of them. Successful companies utilize the opportunity of constant contact to build loyalty. And how? By giving frontline staff rapid access to adequate customer and product information, thus speeding up problem resolution.

As an example, in the mid-1990s, Citibank India changed the rules of competition with its campaign “The Citi never sleeps”. It was the first bank to introduce phone banking to the Indian customer where he could call and transact anytime — day or night.

By announcing that it worked 24×7 for its customers, in striking contrast to its competitors who operated strict business hours, it raised the bar so high that it enjoyed unassailable competitive advantage and high brand recall for a very long time. This was made possible by ensuring information availability to employees at all times.

Read the entire story here.

How I Became a Project Manager

I thought this might be an interesting topic to write about.  Really…how many of us said that we wanted to be Project Managers when we grew up?  I was going to be a baseball player, then a racecar driver, then a lawyer and when I first entered college – a pharmacist, believe it or not.  I switched to the MIS track and came out of college as an application developer.

The Beginning

My first 3 or 4 years were spent coding in COBOL and writing proposals for long-term government contracts.  After one of those contract wins, I took the role of Configuration Manager on the project.  I’m really dating myself here, but in the early 1990’s I switched to Project/Program Management when I was offered a key position on one of the contracts we were performing on with the US Department of Education.

Couldn’t Code Forever

I recognized early on that I wasn’t truly interested in coding forever.  I needed the interaction with the customer and to lead projects and oversee tasks from beginning to end from a higher viewpoint.  I jumped at the chance to become the Configuration Manager on the Guaranteed Student Loan project we had just won.  I managed all change control for the project including leading the formal Change Control Board and managing a small staff.  Switching to the Project Management path came a couple of years later but was still more like Program Management than Project Management because it was really overseeing on-going activity on a five-year government contract, not running multiple engagements from beginning to end like I think of more traditional project management roles.

My first taste of performing the type of project management that I perform now came in 1998 when I went to work for Rockwell Collins handling their internal internet, intranet and extranet projects and leading a small team of web developers on these efforts.  I thoroughly enjoyed the challenge of overseeing those projects from beginning to end – even handling the ‘sales’ side on these internal projects and sometimes managing up to 10-15 live projects at a time.

Except for a stint as a Corporate Applications Development Manager for a large gaming/hospitality entity here in Las Vegas, I’ve pretty much stayed in the project management track handling usually 4-6 projects at a time.  I like the challenge, I love the customer handling and interaction, as well as the oversight responsibilities for the delivery team.  I’ve found my niche…I’ve found what drives me.  When I need a taste of innovation, I’ve been able to get that from consulting work with smaller organizations helping them either organize their PM practices, incorporate new or better practices, fix problems they are having with customers and solutions and in some cases just help them figure out a better way to do business.  These activities don’t really follow a PM path so they tend to feed the entrepreneurial spirit in me.

Early Mentor

My real career turn from developer toward project manager came from my early mentor/manager who discussed my career path at great lengths with me on many occasions.  From my answers could tell that I was aligning more with a project management interest.  He helped guide me in that direction and helped me to find roles on proposals and other projects that would get me the experience and the foot-in-the-door situation to be able to move into those types of roles.

Your Feedback

That’s my story in a nutshell.  I welcome any questions you might have and I’d also like to hear how some of you became project managers.  I still haven’t had any of my kids say they want to be a project manager when they grow up so I know it’s a discipline you really just ‘happen into’ more than choose, for the most part.  Go ahead…send me your stories.