What are the first steps to take when given a new project?

Question

After you've resisted the urge to run towards the door screaming, what are the first two or three things that you do to get your thoughts in order when you have been given a new project? I tend to start to think of the desired objectives and start to sketch out what I know, then develop high level plans from there, but how do others approach it?

Answer 1

When starting a project, here are the things that I consider:

• Define the Scope

Defining the Scope of the project is perhaps one of the most important pieces to ensuring success of the project. It's important to get everyone together in the room, from the technical team, client, sponsors, my manager, and anyone else with a stake in the project, and clearly define what we are and what we aren't going to do.

This is tough and has taken me time to learn that it's better to ask these tough questions now than deal with scope creep later because the scope wasn't clearly defined.

• Define the Specification

The next thing I think about is the specification. This is as important as the scope because it is essentially the architectural plan -- in a software project -- for how the features will function. I work with the client back and forth to clearly define the functionality. I take the spec to my technical team and then send questions they have back to the client until we eliminate as much ambiguity as possible.

• Define the Timeline

The third thing I think about is the timeline of the project. Depending on features and estimates from the technical team, we may offer suggestions of which features to eliminate from the spec when the client is more concerned with timely delivery. We may also reduce the scope of certain features in order to fit the timeline.

• Define risks

The team working on the project may be called away to fix production level issues. The client's API may not work exactly how they explained. The client may realize that the defined features may not be what they were looking for and hence may want to change the spec. The client may decide to cancel the project. We document as many of these as possible and try to stay one step ahead.

Answer 2

Once I have read the available documentation so far, I already start building the WBS and WBS Dictionary, even if it only has a few lines. I also add elements I know will be required from experience (better to have them chopped out explicitly then to 'forget' them because no-one said so ...).

I also draw up a list of possible stakeholders (involved people, SME's already assigned, departments affected, whoever ...).

Then I visit them individually to see what they have to say about this WBS and about the project in general (objectives, requirements, risks, other people that I might need to see, concerns, ...). After each interview I update my preliminary WBS and send it to them for review. Main stakeholders first, for instance, if the sponsor is already known I visit him/her first, etc..

After a few meetings I already have enough material to draft the beginnings of a charter (or initiation document, whatever you may call it), which I take with me in my interview rounds.

Only when I have all individual points of view, is when I start scheduling joint meetings with several stakeholders to get agreement on the points that are unclear, different, contradictory etc., as appropriate.

Answer 3

Outside of the answers above which relate to the specific project at hand, you also need to decide what your plan is for project administration and housekeeping. Answers to these questions are somewhat project independent and have more to do with the culture you are working in and the tools you have available. Some things to consider:

• What tools will you use to track schedule, budget, issues, risk, minutes, actions, etc. MS Project, Sharepoint, Excel, Basecamp, Whiteboards? Do you have a network drive assigned and a default folder structure?
• What is the method and format for your incoming and outgoing status reports? Do you have a powerpoint deck laid out to present progress to executives?
• What supplies do you need? Whiteboard markers ( always run out ), pens, paper, stickies, staples, binders, printer paper, coffee, candy? Who will keep this stuff stocked up for your teams. How can you buy a USB stick if you need one without having to wait 10 days for a requisition to be signed by a VP.
• How will you manage meetings? Do you have rooms? Scribes? Whiteboards? Conference lines? Screensharing? IM?
• How will you manage people based information? Contact details? Vacation calendars? Email lists? Physical / Logical Security for building access, software, folders, etc.
• How are you going to manage / house your documents / deliverables? Will you put these under change control? Who is allowed to change scope documents, schedules, etc.

I could go on and on. The important thing to think about is the scaffolding that you want to put up to manage the project. When you are in the thick of things it is nice to know that you have thought through all of this.

Answer 4

First thing I consider when given a project are people. All sorts of them:

• Project team
• Stakeholders
• Client
• Sponsor
• Subcontractors
• Whoever else might me engaged

Maybe it's a bit counterintuitive as it basically means I don't think about the project itself in the first place but I believe that great people would fill most of the gaps which may be there, while wrong people can ruin even a sure-shot project.

I don't think about project team only -- we'll be building the thing, share good things and bad things but that's not everything you need to remember about.

Another key folks are stakeholders and sponsors -- if you deal with stakeholders who don't really know what they want and have enough power to enforce whatever they want at the very second project is going to be hard. On the other hand if you happen to work with reasonable people in these roles it would be hard to overvalue their impact on project.

Then we have client. They might help or obstruct or not give a damn. Either way it will affect the project.

And there is all the rest who, depending on a project, can also have significant impact on the project team. Like subcontractor who you end up fighting with etc.

At the end of the day these are people who make or break the project using thousands different methods. So that's exactly where I direct my first thought to.

Answer 5

Read more about Initiation Process Group in PMBOK. You start a project with (in this specific order):

• analyzing of business needs
• cost/benefit analysis
• stakeholder analysis
• project charter

Once Project Charter is approved by a project sponsor - you may start spending money and human resources, in order to deliver project scope in time with required quality.