Companies can always find parts of their business in need of improvement. Maybe it’s shipping, resource management, customer service or interpersonal communication and so on. In certain instances one part of the business might do seemingly well, while another—related part of the business—doesn’t.
Take project management for example. Let’s say we have a game company that does a relatively good job of managing its product projects. On paper this company has established product scope, budget, allocation of resources, production timeline, etc. Maybe they have some execution issues, but overall they understand and stick with the fundamentals of good product management. We can say with relative certainty that their version of product management is well understood.
For any company that’s a good start to the proper execution of general project management, but no guarantee that other projects or business initiatives besides product management will see proper execution. However, these fundamentals do provide a springboard the company can use to learn new project management skills to accomplish their goals. In addition to understanding the correct steps and necessary skills to execute good project management, there are some ancillary practices necessary to the smooth function and transitions from one step to the next. I’ll try to review each one in turn. Before I start, however, I’ll need to create a working example to discuss. This will also entail outlining the relevant company positions and responsibilities, as well as a sample non-product example project.
Working with the aforementioned “game company,” my sample scenario is one where the game company wants to run in-store events by agents of the company.
Speaking of projects, here is the definition of a project according to Sebastian Nokes.
“A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.”
The first thing to note is that a project is a temporary endeavor. Do projects become permanent endeavors? If they’re properly executed they shouldn’t. Projects should have a beginning and an end. The finished project, whether it’s a product, another deliverable or otherwise should have a finish line. This finish line is detailed by the project’s unique goals and objectives as outlined by the project’s scope. The next thing to note about projects is that they’re typically constrained by time, funding and resource availability. I’ll discuss these constraints in greater detail later, but suffice to say that good project management entails solid awareness of potential project constraints. This awareness will help a business create a well-defined project scope. The last part of the definition that’s important to note is the idea that projects should “bring about beneficial change or added value.” Most companies will enjoy either a very vague or very specific idea what change or value will be added by a project. Understanding the value added by a project will impact scope, project constraints and so on. As I like to say, value added can help determine if the “juice is worth the squeeze.”
The next concept I want to tackle is a couple forms of project management. While there are literally dozens of different project management styles, I want to specifically mention two. The first is the traditional project management outline. Traditional project management is defined by five stages.
Initiation
Planning and design
Execution and construction
Monitoring and controlling systems
Completion and finish point
There are many industries that use variations of these project stages. For example, when working on building design and construction project, projects will typically progress through stages like pre-planning (or pre-con), conceptual design, schematic design (CAD), design development, construction drawings (or contract documents), and construction administration. In software development this approach is well known as the waterfall model. A potential downside to traditional project management can occur when larger projects of undefined and ambiguous nature suffer from a high degree of uncertainty during the planning stage. Overall, however, traditional project management’s actual stages typically follow common steps to problem solving—”defining the problem, weighing options, choosing a path, implementation and evaluation.”
During my tenure in software development I utilized a variant of the increasingly popular method of Agile project management known as Scrum. I’m going to be a little cliché here, but Scrum is:
“Scrum is a way for teams to work together to develop a product. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.
Scrum starts as a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.
However, Scrum is much more than a simple framework. Scrum supports our need to be human at work: to belong, to learn, to do, to create and be creative, to grow, to improve, and to interact with other people. In other words, Scrum leverages the innate traits and characteristics in people to allow them to do great things together.”
You’ll immediately notice that the two management types vary considerably. Which one is the best fit for our sample project? Before we decide, lets take a look at the company setup and the suspected stakeholders in the sample project.
Our game company has the following individuals at their disposal for this project:
Game Line Boss
Company Agent Manager
Project Developers
Game Agents
Up first are our management positions. The Game Line Boss is the guy responsible for making most of the decisions regarding the game line. Maybe he doesn’t have complete fiscal, decision-making or fiscal control, but he has enough to be the day-to-day GM of our sample game line. In most project management approaches the Line Boss would be our project stakeholder.
The next fella on the management list is the Agent Manager. This gentleman manages the various company agents, events and agent-store-customer interactions. In practice the Agent Manager should be a combination of HR, Business Development and Customer Service guru in charge of entry-level customer and market interactions. The Agent Manager is also a stakeholder in our sample event project (we’re using his agents). Other stakeholders could include any management above the Game Line Boss or stockholders, but for our discussion we’ll “assume” they’re on-board for this project.
Below our manager positions are individuals involved in the project. This would include project developers like writers, layout persons, marketing, artists, etc. Basically, anyone involved in the project. Project developers may be freelance, full-time employees or volunteers. Game Agents also fall under the heading of project developers, but I placed them in their own category to help differentiate between “backend” and “frontend” development teams—which we’ll get into later.
So we’ve established our basic project: run in-store events using company agents; we’ve established the stakeholders; we’ve defined and reviewed the definition of a project, and briefly talked about two different types of project management. Now we’ll start work on the actual project management of our sample project. For our sample game company and project we’re going to use the traditional method of project management. The traditional method is a suitable companion to their existing method of product management and will encounter the least resistance if implemented.
The first steps in project management are defining what is needed toward establishing a project timeline, setting of project goals and allocating project resources. These steps will help you to define the work that needs to be done—or in other words, define the scope of the project. Skipping any of these steps could cause the project to fail, and I should note that many project management steps may feel, or are also inter-connected. There’s definitely the sense of spillover from one step to the next and one stage to the next that good project management can keep organized.
In traditional management, the first stage is called Initiation, and should include a plan that encompasses the following areas:
Analyzing the business needs/requirements in measurable goals
Review of the current operations
Financial analysis of the costs and benefits, including a budget
Stakeholder analysis: including users, and support personnel (read: project developers) for the project
Project chart: including costs, tasks, deliverables, and schedules
The key project controls needed at this stage are an understanding of the environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. For our sample project we’ll generically outline this stage with the following information:
Needs & Measurable Goal
- Increase Customer Base
- Have 2 new players participate each event
- Increase Sales
- See the sale of 4 Alpha Strike products per calendar month
- Increase Market Reach
- Run two events per calendar month
- Centralized Agent Program
- Event support; Agent Program process changes; Agent Reports
Current Operations
- Current store events are decentralized, disorganized and completely volunteer based with little to no company support, outline or direction.
Cost & Benefits
- Budget
- Salaried Hours included in company’s operations budget
- Benefits
- Improve overall health of game line, increase revenue and market share, better trained and motivated agents
- Costs
- Volunteer Hours
- Salaried Hours
- 10% of the MSRP of Products Sold as Store Credit for each Agent
I’ll skip Stakeholder Analysis for a moment, but say that all of the company members mentioned earlier will be involved in the project.
After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is to plan time, cost and resource use adequately to estimate the work needed and to effectively manage risk during project execution. Project constraints are identified at this stage, and worked into the plan. As with the Initiation stage, a failure to adequately plan greatly reduces the project’s chances of successfully accomplishing its goals.
Project planning generally consists of:
Determining how to plan (e.g. by level of detail)
Developing the scope statement
Selecting the planning team
Identifying deliverables and creating the work breakdown structure
Identifying the activities needed to complete those deliverables and networking the activities in their logical sequence
Estimating the resource requirements for the activities
Estimating time and cost for activities
Developing the schedule
Developing the budget (if any exists)
Risk planning (incredibly important)
Gaining formal approval to begin work (if required)
Additional processes such as planning for communication and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable. Since our game company is geographically distributed across the globe, planning for communication and providing for deliverables will be key to successfully executing the in-store events project.
Our game company will utilize three avenues of communication. The first will be a centralized Basecamp account for use by the project managers, deliverables and communication regarding said deliverables. The second form of communication will be through email. The final form of communication will be an Agent-only forum board for Agent-Agent Manager communication and feedback.
Since this article is beginning to get a little unruly, I’m going to end it here. While writing it, I realized that I would have to make some actual project decisions and then justify them for the example. To help facilitate this teachable moment, in my next article, I’ll create and write the entire project, and make the appropriate notations where necessary.