Resource Management is defined by the Project Management Body of Knowledge in four different categories: resource planning, resource acquisition, project team development and team management. In the past, I’ve written about how to manage a team and difficult resources. But defining your team and what you, as a PM, are responsible for is a little different. Resource Planning focuses on understanding the scope of a project and defining the types of resources needed to complete it. Depending on the organization you work with, the PM may or may not be responsible for these efforts. It will depend on how good the company’s work intake process is and how closely managers maintain their resource pool. Resource Acquisition focuses on defining the needs for the project, and obtaining the right resources for the team and other resources and tools available to manage the effort. Over several years, I’ve had a mixed bag when dealing with and managing resources. I’ve been placed at some locations where a project was scheduled to start two weeks after I arrived. All of the major resources needed, tech lead, analyst, etc., were already assigned. All I had to do was schedule the kickoff meeting and we’d be on our way. Any additional resources needed were pretty easily obtained and available. On the other hand, I’ve had some clients who literally gave me a document that may or may not have qualified as a business case and told me to figure it out. That included contacting the project sponsors and going to each resource manager in order to create estimates, build a Rough Order of Magnitude estimate and define the team and solution. All of that’s necessary before you can really kick off a project. It’s this last case that I want to talk about. How do you, as a PM, start from scratch and succeed, and what are some typical obstacles you might run into and how do you manage them successfully? To get started with the project, you need to:

• Understand Your Basics: As the PM, you need to figure out what you have to work with. You want any materials that might be available, but some specific items to look for are a project charter document, scope and budget. Without a project team around you, it’s necessary to review the available items to help make the right decisions going forward.

• Resources: Once you understand the basics, you should be able to pull together the resource types you’ll need to drive the business requirement effort. If you’re kicking off the project, you’ll minimally need to have an analyst. Depending on the structure of your group, it might be a systems analyst, a business analyst or a combination of both. Sometimes the client will also provide a BA from the start of the project.Some additional resources that are helpful, but not necessary, during the initial phase are technical lead(s) for major development groups, a QA lead and developers. If they’re not brought in for the initial discussions, they should be engaged as soon as business requirements are complete.

Resource Acquisition

Once you get the basics in line, you need to start defining the project and estimate the resources necessary to move the project forward. This is where things can get tricky. Not only do you need to define “when” the project needs to be completed, but you have to find the resources and get them allocated to meet your needs. In order to manage the effort involved in obtaining your resources, you’ll need to arm yourself with a number of things. This process is Resource Acquisition. The tools below will help you during this process, and should be kept at hand throughout the project timeline to ensure the right roles are filled with the right people.

• Project Management Plan: This is the essential tool that you need to start the process. The PMBOK defines it as a formal, approved document that guides both project execution and project control. The plan ensures that the team documents assumptions and decisions, drives communication with stakeholders and contains the basic project scope, cost and schedule baselines. A project plan can be detailed at any level. Most of mine are fairly simple but they can be comprehensive when it’s necessary.

Once you have the scope and cost together, you should start building the project timeline. High-level at the start, it will need to make some assumptions to get through your analysis and solutioning phases (Initiation, Define, Design). You should be able to take the basic resource types on the project or look at similar plans to build your base plan. The timeline should also contain all the major milestones that impact your organization (not just the simple Phases of a Waterfall or Traditional methodology). The project plan can include the following items: Scope Management, Quality Management, Resource Management, Communications Management, Change Control Management, Risk Management and Budget Management. There are other areas you can include, like Procurement Management, but they should be based on the needs of the project and organization. We’ll review putting together a robust project timeline and resource plan next, to ensure we can start having the right conversations with resource managers.

• Project Timeline: In order to get the resource conversation going, you need to develop a project timeline. This is essential to start any conversation with a resource manager. The timeline shouldn’t be developed with hard dates, but should be done in weeks or months to illustrate the project’s potential time frame. If you lock yourself into dates this early, it may be problematic trying to explain why the “original dates” didn’t hold true.The project timeline isn’t just a schedule of activities, it also includes assigning resources to each. When starting to create a timeline, I always assume I can have 50 percent of a resource’s time. This is especially true in a Waterfall/Traditional environment. If you happen to be in an Agile team-based company, then you’d obviously assume 100 percent unless you see otherwise to be true.

In your timeline, you should define each of the project’s major milestones and make some assumptions about how long each activity will take. If you don’t have the experience to do this, you should ask to borrow another seasoned PM’s plan and copy as much as makes sense. There also might be an existing template to help you. If you do not have a standard tool, the industry standard is still Microsoft Project. If you don’t have that, Microsoft Excel can work, though it’s very manual. The basic high-level plan should include your traditional phases (you can grab this from anywhere), resource roles (not individuals) and projected timeline with activities. PMBOK Phases are: Initiate Plan, Execute, Monitor/Control and Close. Your organization may have major phases similar to some major corporations that I’ve worked at – Initiate, Define, Design, Build & Test, Production and Close. It’s a tad different, but is easier for some management teams to digest. Keep in mind that the “monitor and control” phase is consistent throughout the life of the project. In each of these phases, there are some basic milestones you should capture:

• Initiate: This is where you capture all the activities that I have mentioned above. It’s the time when you form the team, put together the major plan, acquire resources etc. All of these items can be considered tasks on the project plan, with start and end dates to be tracked. If you don’t set those up, you may lose sight of how long each item takes and the project’s earlier phases can drag on a little too much. At the beginning of the project, it will be one of the most detailed phases because of the knowledge you have to get started.
• Define: This is where you gather the business requirements and get those locked down. It’s important to have the business side provide them to the team and review them. Most of the time, business partners don’t provide fully vetted requirements. There is typically a timeframe in which the team needs to do some Use Case development and understand current processes, to ensure the technical team fully understands the needs and agrees that the requirement document contains the appropriate items. This is also the phase in which the team can start to look at how the project will fit architecturally within current systems, and start making some broad decisions about the effort.
• Design: This is the phase when the functional requirements and solution design comes together. The project team should be describing what the end result will look like and be putting together the “how” to solution it.
• Build & Test: This is pretty simple: It’s where the project team creates the solution based on the output of the Design phase. At the end of this phase, most projects “Go to Production” as the final step. You can also consider including the Close items here.
• Close: This is the time when teams should review the project as a whole and provide feedback. I tend to leverage the Retrospective from Agile teams because it feels more positive and doesn’t place blame. It is a forward thinking tool – how can we do better? How you close out your project will depend greatly on your company and the flexibility of your organization.

Once you’ve built this out, you’ll need to start working with resource managers to gain the right folks for the project. This process is called Acquisition. While resource managers may be aware of the project, it’s really your job to educate and provide the means for them to make decisions. Your plan should be detailed enough to drive conversation. Your goal is to get a resource assigned with the right level of knowledge to help drive forward the “Define” and “Design” phases. A couple of factors that can come into play while you’re having these conversations:

• Expected completion date from client (if known)
• Known risks and/or watch points for the project effort

Having these defined, or started, may help drive which resources are assigned. For example, if you have flexibility in the production date, you may be able to leverage a newer team resource who needs extra time to learn and grow. If your timeframe is tight, you may need to haggle for a top producer. The same holds true for risks or watch points – if you have any that are known, they will possibly influence decisions. Nowadays, you can have resources just about anywhere in the world. From the U.S. to China or Ireland, you can work with anyone. If you’re fortunate to work with local resources, you’ll have fewer challenges in planning. If not, you need to be aware of time zones, cultural differences and the like as you start off your new working relationships. Once you have gotten a commitment from the resource managers, you must manage the people who are provided for the life of the project. You may also have situations where you define a need for more team members, or you may lose one for any number of reasons. In order to help drive conversations and keep the project running smoothly, you must stay in tune with the project team.