Discovering the Real Requirements and Resources for a Project

January 18, 2011

When you’re responsible for a project, one of the first things you’re supposed to do is determine the requirements for the project. In other words, what exactly do the people who asked for it want? This is much more complicated than it sounds, and much has been written about eliciting requirements and getting them written down in a coherent manner.

In many years of managing projects and teams of developers, I have learned to ask some questions that you might not think of while you’re gathering requirements. You may consider these questions as “tricks of the trade” that could help you keep out of trouble.

Here are the questions:

1. Who has veto power over this project?

One of the most startling outcomes for a young project manager is to have the project cancelled abruptly after pouring a lot of energy into directing and supporting the project and the team performing on it. To head off such an outcome, you should ask this question early in the project definition phase. The answer, which could include the CEO, the Chairman of the Board, or one of the Founders, gives you an idea of who should be included in your regular status updates.

You also can discreetly inquire as to whether those people with veto power have any feedback for you and for the project team, even if they don’t show up on your organization chart (at least not anywhere near your project team). This is the art of politics, and you may as well get good at it.

2. How many of the project team have in the past been interrupted with high priority, preemptive requests from outside their project?

No matter how carefully you estimate manpower and workload, your estimates will be way off the mark if people outside your project can and do take away your team members’ time with non-project work. It is best for you to gauge this “distraction level” as a percentage of the team’s effort, so ask this question early in your project estimation phase.

There are two aspects of this kind of distraction. One is pure non-project work requests that take away team time when they do things like fix a problem with the CEO’s PowerPoint slides, or respond to a key customer’s emergency. The other is when project team members are assigned to more than one project, so that they are switching between the project you manage and a project (or two or three) that are managed by someone else.

When this is the case, you must not only divide the projected available team time by the number of concurrent projects, but also further degrade the time by the “context-switch” factor, which I estimate at 10% per context-switch. In other words, if a team member is working on two projects at once, each project may get 45% of a full-time member at best. For three projects, it’s .8/3 or 27% of full time. Of course, if the context switch happens during a single day, the percentage loss is much worse than 10%. You should make your estimates accordingly.

3. What is the available budget for tools and other capital equipment? Whose approval is needed to actually spend this money?

You want to know how much you can spend on tools before you start, because having the right tools is often crucial to making a team productive. If the development work is in software, this is particularly crucial to your planning – having the wrong tools can not only make productivity low, it can get in the way of your ability to hire the best people for the team.

Having determined how much money is “available,” you also need to find out what it takes to spend the money. Often, in larger organizations, the path to making capital outlays is long and arduous. If it only takes a written justification from you and approval from your immediate boss, then you’re in a relatively normal situation. If a committee has to meet in order to approve your purchase, then you had better find out who is on the committee, how often they meet, and what kinds of purchases they have approved (and disapproved) in the past.

These three questions may all be part of politics. But then knowing what it will take to succeed may influence which project management jobs you take on. Be forewarned and proceed with your eyes open and questions ready.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––

John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.

John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way , was published in May 2010. http://bit.ly/9pX1wS