Brainstorm, Plan, and Schedule Your Project

Learning Objectives

After completing this unit, you’ll be able to:

• Describe how technical project managers work to understand the problems, desires, and expectations of employees and clients.
  
• Include security policies that consider relevant threats and security risks in the project design phase.
  
• Translate big picture goals into budgets and timelines.
  
• Explain how to gain alignment and earn the trust of stakeholders.
  

Navigate to Your Destination

Can you imagine starting a car trip to an unfamiliar destination without a map or navigation system? How would you know where and when to turn, or how long it will take you to get there? Just like maps help us reach our destination on time and safely, managing projects starts with formulating a plan so you know where you’re going, how long it will take to get there, and what to expect along the way.

The first step to successful technical project management is understanding your client’s business and technology needs. The system or service you deliver will need to integrate into the organization’s existing operations, so you must have a clear understanding of the industry, business, and environment you are in. 

Design Sessions

Typically, you’ll start your project with a design session to help you understand your client’s needs and map out a plan. In design sessions, you brainstorm with a small group of participants to understand ideas pertinent to the problem you are looking to help solve. It’s key to ensure you have the right people involved based on their knowledge of the issue and area of expertise, including the security team. The ideas you generate will be turned into a proposal about how best to resolve the issue under consideration. Questions to ask during the design session include the following.

• What problems do customers/clients confront?
  
• What privacy challenges and security threats do you face?
  
• Are there policies we need to follow or develop for project success (including information security policies, or policies related to secure coding practices?)
  
• What risks could affect the project (including both security and non security risks)? Are there certain technical key performance indicators (KPIs) you want to meet, such as increasing system performance by 100%?
  
• Where do you plan to be in the future? For example, the end goal may be to have a system that is both simple to use and versatile enough for a wide range of functions and features.
  

Validating the Project Proposal

Once you’ve answered these initial questions during the design phase, it’s now time to validate whether your proposed approach is feasible. Validating the feasibility of the project involves understanding how business processes work, and whether the proposed project fits into these processes, or whether they would need to change. At this phase, you also validate who operates the system you are working on, and ensure they are on board with the proposed plan and have the authority to execute the project.

You also seek to understand the tools and infrastructure the company is using, and whether they will be sufficient to develop the technology you are proposing, or if new technology will be needed. Finally, you validate what budget the company is willing to invest and whether it is sufficient.

Where the Work Really Happens

So you’ve worked with relevant stakeholders to define the destination, and validated the feasibility of your proposed approach. Next, it’s time to look at how to translate the big picture goals you just validated into budgets and timelines. At this stage, you translate the information you’ve gathered during the brainstorming phase into a project plan.

In delivering the solution, the work boils down to the triple constraints of cost, schedule and scope, or how much money are you willing to spend, how much time do you have, and what do you want. These dimensions play off each other, and technical project managers must recognize that a change in one of these dimensions will result in a change in one or both of the other two. Thus if you want to get new features (scope), you will need more money, or more time, or both. Getting the project done faster (schedule) will require more money, or less scope, or both. Delivering a project cheaper (cost) will require more time, or less scope, or both. None of these dimensions is independent of the other two. The project manager must remind stakeholders, even when they are agreeing to a change, that there is always an impact to the other dimensions. Let’s take a closer look at each of these dimensions.

Scope

Scope involves achieving the project’s goals. In defining the scope, list three to five goals that you hope to achieve during the project. For example, increase gross sales by 5%. You then use the project plan to provide strategic direction by making sure the goals line up with the organization’s strategic priorities. In putting together the project plan, you include information security objectives in addition to overall project objectives. How will this project work to reduce the number of incidents and improve confidentiality of information? If you don’t explicitly articulate these goals, they risk falling by the wayside.

In some projects, especially those that use an agile methodology, the key to defining the scope is to define a minimally viable product (MVP). This is the version of the product with just enough features to satisfy early customers and provide feedback for future product development. The MVP will be the focus of your initial work, or sprint. Once delivered, your team will use customer feedback to iterate on the product and make incremental improvements, incorporating more complex and time consuming customer requirements into future sprints as you go. 

Schedule

Once you’ve defined the scope, the next step is to set the timeline. Stakeholders look for you, as the technical project manager, to create the roadmap. You break down high-level goals into realistic, actionable steps for all involved in order to deliver by the deadline.

Cost

Lastly, you need to track the budget. Depending on the project you may need to create estimates for travel costs, telephones, utilities, or office supplies, in addition to computer systems. What time frame is the budget for? A year or the next five? What assumptions are made about the budget? Do we need additional resources to hire for specific skill sets to support the project? How many people are you assuming it will take to do the work? Think about what will persuade decision makers to support the budget, given their limited resources and many requests for funding.

You’ve finished documenting your project plan so what’s next? It’s time to continue the work of gaining alignment and winning the trust of stakeholders.

Gain Alignment and Earn Trust

Meet Christopher. Christopher Akers takes on many technical roles for Hive Javilud, a cybersecurity company that offers threat intelligence products to its customers. One of his roles is to lead the development of a new threat intelligence reporting tool that is being designed to help customers understand the latest threat trends and countermeasures. Christopher knows that in order to successfully manage this project, he’s going to need to get the buy-in of all the necessary stakeholders. 

Stakeholder management is a critical part of Christopher’s job. He works with stakeholders from across the company, including the data analytics team, the threat intelligence team, and the application development team, to understand what constitutes a “win” and what constitutes a “loss” for each one. His work is to make each stakeholder a winner.

To do so, Christopher facilitates discussions between the stakeholders, so that the criteria that makes each stakeholder a winner is well understood. He asks what the new threat reporting tool needs to do to address each of the stakeholders needs. He manages conflicts between teams. For example, the developers may want to push out a new feature as fast as possible, while the security team needs them to adhere to a different timeline that allocates time for security testing before deployment. Christopher doesn’t give up until all stakeholders agree on the proposed approach.  

Part of managing stakeholders is also clearly defining roles and responsibilities for the project, including those related to information security, such as the chief information security officer (CISO), information security auditors, developers, and systems administrators. Christopher makes sure he knows who is in each of these roles, what their responsibilities and accountabilities are, and who needs to sign off on what parts of the project in order for him to meet his goals. It’s a lot of work but worth the effort!