Article
About the Author
Meri Williams
Meri spends her days managing projects at a large multinational, and her evenings writing and developing web sites. She writes at Geek | Manager, as well as on her personal blog, and recently started Make Me A Speaker!
The Principles of Project Management
You've already got an understanding of the basic project life cycle, and we've just talked through some of the underlying principles of project management. But I bet you're itching to actually do something. In this chapter, which is taken from SitePoint's new title, The Principles of Project Management, we'll talk about the work that comes before the project life cycle -- finding possible projects, working out which projects are worth pursuing, and getting to know the different groups of people who will be involved in any project. Finally, we'll discuss the process of actually initiating a project.
I know -- we're covering a lot here! But as always, you can download this chapter in PDF format to read offline.
In each of the sections that follow, you'll find a discussion of what the process is and why it matters, followed by tools and best practices that will help you get your project off to a flying start.
Discovery: Finding the Projects
Projects don't just spring from nowhere. Although many project managers only get involved when it's already been decided that a project will be undertaken to achieve some end, there is, of course, a phase before this: discovery. Discovery is the process by which the organization reviews the available opportunities and decides which of them will become projects in due course.
Ideally, the discovery process should ensure that the best opportunities are pursued -- not just those that were mentioned first, or those that have the loudest supporters. Where this process is undertaken, it's usually combined with some sort of portfolio planning through which the potential projects are matched against the resources or capabilities of the organization itself. The eventual result is a list of projects that are truly the top priorities.
The sad reality is that in many cases, there's either no process at all for discovery and portfolio planning, or the process that's in place doesn't result in the selection of projects that will deliver the most value. It's also true that as a project manager, your influence may be very limited at this stage -- after all, in many cases, you won't even know about the potential projects until one is assigned to you!
However, understanding what has been discovered, and how the project that you're managing came to be started, is very important. It can tell you whether the project is truly of high value to the organization for which you're working (either as an employee, contractor, or service provider) or whether its potential value still needs to be ascertained. It may also give you early insight into the complexities you might have to face during the project.
If you find that little or no discovery work has been done, don't despair -- do it yourself! Find out why people in the organization think your project is important. Understand what they're expecting the project to deliver -- try to focus on what it means to them, not the nuts and bolts of what will be built. If their answers suggest that they don't think the project matters, find out where they think the time and effort would be better spent.
Your first instinct will be to protect your project, but you might find an opportunity for another project that will deliver even more value. Even if you don't end up jettisoning the original project and taking on the new one instead, bringing it to the attention of the stakeholders within the organization will make you stand out as a project manager who really cares about the good of the company, not just your own projects.
Example 2.1. Choosing the Wrong Options
Imagine there's a team at a company you're working with that deals with customer orders. The team members have identified a number of opportunities:
Remove manual work from current processes.
Many in the team feel that they spend almost all their time shuffling paper, rather than actually dealing with the customers.
Speed up inventory checking.
When a customer places an order, the team members have to call up the inventory team to find out whether the goods are in stock or not. Making this process faster would improve their efficiency greatly.
Improve tracking of customer orders, queries, and complaints.
Currently, all tracking of customer interactions is done manually. There's actually one person in the team whose full-time job is collecting the information and putting it in an Excel spreadsheet!
Allow customers to interact in more ways.
A number of customers have signalled that they'd like to be able to email the team as a whole, or to input queries and complaints online.
As you might have guessed, the opportunities above are ordered in terms of importance. The team feels that reducing their manual work is most important, with the inventory tracking improvements and customer tracking automation coming a close second. Once these fundamental issues have been fixed, the team feels that it can start work on items that will really benefit the customer -- introducing a web site and email addresses so they can log orders, queries, and so on.
When people from elsewhere in the organization get involved, however, they get very focused on the web site for the customers. Marketing can see that this will be a real selling point and the sales teams think that it will delight their contacts. They don't realize that in order for the customer web site to be successful, the team needs to have all the other opportunities addressed first.
The first you know about any of this, however, is when you're brought in to build the new customer web site. You get started working on it, but are finding that the people from the team who deal with the orders are very difficult to work with: they won't answer questions clearly, don't turn up to meetings that you've organized, and don't answer emails unless they're reminded to again and again. You're sensing hostility, but you have no idea why -- you've only been there a week. Surely you can't have offended them already?
You get in touch with some of the IT guys that you know from the last project you worked on for this company and ask them what's up. They explain about the other projects that this team identified ... and that the team actually thought those other projects were more important. However, someone in the marketing team, having heard about the possibility of the web site being developed, promised one of the big customers that it would be ready soon, so management decided to prioritize this project over the improvement of the systems.
Now you understand why the team is so unresponsive! They're upset because their own needs have been ignored, and now you're working on the project that they've been forced into prematurely.
At this point, it can be very easy to get depressed or start panicking. What if the team continues to sabotage the project and you get blamed when it isn't delivered? You don't have the power to go back and work on the project they really wanted to happen, so perhaps you should just give up now ...
The point, though, is that now you understand what was causing the team to be unhelpful and unresponsive. Armed with that knowledge, you can do something about it!
As we've already discussed, often the project manager won't be involved in deciding which projects will be undertaken. In this particular situation, however, you can try to mitigate some of the impacts of the web site project being prioritized over that of updating the existing systems.
Firstly, you have a discussion with Pamela, the team member who's been the main cause of friction so far. You explain that you understand there were originally other projects on the cards, and ask her to clarify for you what they would have entailed. As she talks, you realize that some of the elements of the existing manual process are going to be problematic for your project as well -- for instance, it won't be possible to determine whether or not an item is in stock without someone making a phone call.
In this particular example, there's an obvious route forward -- help to identify the modernizations of the existing system that are required for the web site project to be a real success. Then push either for these to be brought into the scope of your own project, or for a separate team to be set up to deal with those issues in parallel.
However, even if you won't be able to influence the organization to work on the productivity improvements as well as the site, just having spoken to Pamela seems to have improved relations immensely. She commented that you were the first one of the "techie guys" who had taken the time to really understand why the team is so frustrated. She has started responding to your queries and emails and even seems to have told the rest of the team that they should help you out as well.
The point is that without understanding where your project's roots lie, you're flying blind. By investing some time to find out a little more about how the discovery work was or wasn't done, and how the decisions were made, you can gain a valuable insight into the challenges you might face, day to day, on the project. This approach can also give you an early warning of any office politics that might make your life difficult!