Skip to main content

Tag: Plan

The Convergence of Security and Project Management

In the rapidly evolving world of IT, we frequently hear about vulnerable data being stolen and disseminated from renowned organisations, or businesses reporting disruptive attacks such as Distributed Denial of Service (DDoS) assaults that bring their operations to a halt. While some of these disruptions may stem from a small bug that was not captured during testing, there are instances where the cause is much more serious.

The financial and reputational impact that these attacks have on organisations are huge, often requiring a substantial amount of time and effort for a full recovery. This underscores the importance for the organisation to have project managers who, leveraging their experience from past projects and their background in security training, can effectively assist the project team in recognising common vulnerability points and taking proactive steps to address them.

In recent years, a series of incidents have underscored the necessity of making security a critical aspect of project management. One prominent case is the Anthem Inc. Data Breach.


The Anthem Inc. Case

Elevance Health, formerly known as Anthem Inc. is one of the largest health insurance companies in the United State. Despite the expectations that organisations of a similar size would have invested significantly in security measures, in 2015, the company suffered a major data breach that exposed the personal and medical information of approx. 78.8 million individuals.

Investigations revealed that the cyberattack began through a spear-phishing campaign where cybercriminals used social engineering techniques to send deceptive emails to employees. One employee fell victim to the phishing attack, granting attackers access to Anthem’s database.

Needless to say, this breach had a significant financial impact on the company not only in terms of legal expenses but also in the effort required to strengthen their cybersecurity measures.


Key Takeaways for Project Managers

The Anthem Inc. security breach stands as a compelling example of the consequences when security becomes an afterthought in project management. This breach serves as a reminder of the critical role that project managers play in ensuring enough security considerations are taken into account throughout the course of the project. To this end, project managers should:

  • Ensure that a robust risk assessment is conducted not only during the project initiation phase, but also during execution and prior going live.  Through these assessments organisations can proactively identify potential security breaches and mitigate them accordingly.
  • Advocate for the integration of security measures into project planning with all stakeholders. They need to emphasise the practice of prioritising security-related activities over adherence to predefined timelines.
  • Loop in subject matter experts throughout the course of the project to ensure compliance with the right security frameworks and meeting all compliance, regulatory and legal requirements.
  • Develop a robust incident response plan as part of the project delivery before the project goes live. This plan should include the identification of key stakeholders and the establishment of procedures and processes to address security incidents.
  • Leverage past lessons learned throughout the entire project lifecycle to avoid repeating past mistakes, while replicating good practices.
  • Effectively communicate security requirements with all stakeholders, ensuring that these are well understood by everyone involved. Additionally, like all other facets of project management, project managers should also ensure correct and timely reporting of progress.


[widget id=”custom_html-68″]


Exploration of Security Breaches Through Three Lenses

To support project managers in ensuring that key security measures have been considered in their project, I often suggest examining their projects from three different perspectives:

Internal Security

One common source of security breaches arises from internal factors, often originating from disgruntled employees or vulnerabilities within other internal systems or networks. While it is extremely difficult to prevent all potential internal security breaches, as sometimes even the most trusted employee can, for various reasons, become a threat to the project and the organisation, project managers play a pivotal role. Through tools like a Risk and Impact Assessment, they can ensure that people and the interconnected systems have the least-privilege access rights to confidential information, including software code and database itself.  A properly constructed Work Breakdown Structure (WBS) and RACI (Responsible, Accountable, Consulted, and Informed) Matrix can be extremely helpful for project managers in determining what type of security privilege should be assigned to whom, when, and under what circumstances.


External Security

When organisations involve external parties, the risk for security breaches increases significantly. These breaches are not only tied to theft and copying of trade secrets, but can also be the result of insufficient security controls on the external party’s side. Furthermore, the situation becomes more challenging when the outsourcing company is situated in another country with a different regulatory landscape.

Therefore, project managers should allocate ample testing time within the project timeline. This entails not only conducting well-thought-out and designed integration testing, but also ensuring that robust security testing is performed on both the third-party and overall system.

One approach organisations usually employ to ensure that security testing is conducted effectively, in compliance with the latest security standards, is by utilising the services of externally renowned and specialised security testing companies to perform these tests.

Finally, in cases where the organisation is outsourcing parts of its software, the project manager should ensure that there is an escrow agreement in place to minimise the risk of the company being left without access to the source code in the event that the outsourcing company suddenly folds.


Technology Lens

Finally, in a world where everything is interconnected, technology and device-related security breaches frequently occur. In light of this, I recommend that project managers keep a comprehensive list of standard security practices to integrate into every project they undertake. These activities include the key tasks such as: changing of default passwords, configuring firewall settings, testing of third-party hardware and software before connecting with company networks and servers, and ensuring the installation of the latest security patches. By adhering to these security measures, project managers can significantly enhance the protection of their projects and systems in the ever-evolving technological landscape.


In an era where information is power and trust is paramount, security is not an option —it’s an absolute necessity that must be integrated into every step and phase of every project and product’s lifecycle. A security breach isn’t limited to a mere disruption in operations. Besides the financial and reputational aspect, it has the potential to impact lives. Hence, this makes security not an accessory to project management, but rather a fundamental principle that ensures the success, integrity, and trustworthiness of the projects the organisation undertakes.

‘Delay Thinking’ Is a Project Success Factor

Often, it is better to spend more time than it is to speed to meet a deadline. Fast is good but not always. When rushing to get something done the probability of causing damage is high.


Delay Thinking

Delay thinking recognizes that there is a delay or lag between an action and its effect. Peter Senge in The Fifth Discipline says that “Delays can make you badly overshoot your mark, or they can have a positive effect if you recognize them and work with them.”

Figure 1 below is a diagram that explains the delay phenomena, he gives the example of the delay between the time you adjust the water temperature in the shower and the time the water reaches the desired temperature. If you understand the delay, you will make sure you don’t get doused in cold water or make the mistake of further turning up the hot.

Figure 1: Delayed Results[1]

What Does This Have to Do with Projects?

In both projects and operations, we make and act upon decisions. We set expectations among stakeholders about outcomes. We are expected to fix problems and do it fast.

Faced with problems we may seek quick fixes by applying solutions that worked in the past or in other organizations. We can be pressured into rushing ahead without doing the due diligence of assessing causes, multiple scenarios, and the impact of differences between the current situation and the ones in which a solution worked in the past.

In time bound projects, there is a tendency to overlook likely delays. For example, underestimating the time it takes to perform predecessor tasks when scheduling resources. The result is the cost of resources sitting idle while waiting for the results they need to proceed.

When we take delays into consideration expectations are realistic and problem resolutions end up making things better rather than worse.


Learning Curves and Change Management

For example, when a large organization implemented a system to reduce the effort of field managers by applying AI to automate their ordering process, they failed to recognize the delay caused by a combination of learning curves, manager resistance to a perceived loss of authority and autonomy, and the need to fine-tune the algorithm used to make ordering decisions. The result was avoidable chaos, supply chain disruption, and degraded performance. The new system was rejected.

The outcome would have been a far happier one had the project plan included a robust training process, “marketing,” and a calibration period with an incremental system rollout rather than a “big bang” implementation. All of these are “delays” that on the surface cause the project to run longer. Though more often than not, when looking below the surface these so-called delays save time, effort, money and reduce unnecessary stress.



What might cause failure to include delays in plans?

Everything has a cause and when we discover causes, we can better avoid repeating failures and making poor choices.

One predominant cause of this failure to consider delays is rushing to get a project completed in a certain time frame. The pressure to get your project done by a fixed date may be driven by many things – the whim of a senior stakeholder, funding availability, the need for resources on other planned projects, legal restrictions, seasonal weather conditions, etc.


When a “get it done by” mandate is in play, pressure, and the anxiety it brings leads decision makers to cut corners, perhaps forgetting that spending more time planning can result in exponentially less time during the rest of the project. Pressure and anxiety also lead to applying quick fixes which overlook long term consequences.

Expediency bias operates even when there is no major pressure to hit a deadline. It is the tendency to prefer quick action over taking the time to make sure there is clarity and understanding about short and longer-term results.

During planning, rushing and expediency bias leads to only looking at one scenario instead of a few. Assessing multiple scenarios opens the decision to useful analysis. But this takes time. When rushing, talk about lags or delays is impatiently squelched. The risk of making a poor decision based on limited information is high.


[widget id=”custom_html-68″]


Quick Fixes – Short Term thinking

Another dimension of delay thinking is the recognition that when resolving a problem, while short-term fixes might remove symptoms there is a delay before the nature of longer-term consequences are experienced.

We are often blind to the long-term effects of short-term decisions and actions. When there is a lag between our action and its effect, we are easily driven by the satisfaction of short-term pleasure and immediate gratification.

Take the decision between eating a bowl of ice cream and a salad. If you are like me, the ice cream is far more pleasing than the salad. And, at the end of the day, you’d look and feel the same regardless of your choice. So why not go for the ice cream.


But factor in delay thinking and you get to see that if you repeatedly opt for the ice cream over the salad the delayed longer-term effects start to show – weight gain, digestive issues, increased blood sugar levels, etc.

Looking at the short and long-term effects makes your decision making more effective. You know what you are gaining and giving up when you make your choice. You can opt for ice cream sometimes, but you are more likely to moderate, assuming your goal is good health. You can remove symptoms with a quick fix, but you had better consider the longer term impact and plan for it.



Awareness is the key.


Being aware that delays are normal parts of experience makes it likely that we will consider them when making decisions and planning projects. Knowledge of the specific delays in your project comes from analysis and experience, your own and your institution’s.

Be aware of rushing and expediency bias and the power of spending more time in planning to playout various scenarios, consider delays and delayed effects, and cause removal vs. symptom removal options and their effects.

Think of what happens when you drop a stone into a pond of still water. Be aware that every action you take has a ripple effect and that the ripples appear over time, radiating in all directions.


[1] Senge, Peter, The Fifth Discipline, Doubleday, NY, 1990 p. 90

Best of PMTimes: The Five Goals of a Project Manager

As a project manager, you need to manage people, money, suppliers, equipment—the list is never ending. The trick is to be focused. Set yourself five personal goals to achieve. If you can meet these simple goals for each project, then you will achieve total success.

These goals are generic to all industries and all types of projects. Regardless of your level of experience in project management, set these five goals for every project you manage.


Goal 1: To Finish on Time

This is the oldest but trickiest goal in the book. It’s the most difficult because the requirements often change during the project and the schedule was probably optimistic in the first place.

To succeed, you need to manage your scope very carefully. Implement a change control process so that any changes to the scope are properly managed.

Always keep your plan up to date, recording actual vs. planned progress. Identify any deviations from plan and fix them quickly.


Goal 2: To Finish Under Budget

To make sure that your project costs don’t spiral, you need to set a project budget at the start to compare against. Include in this budget, all the types of project costs that will accrue, whether they are to do with people, equipment, suppliers or materials. Then work out how much each task in your plan is going to cost to complete and track any deviations from this plan.

Make sure that if you over-spend on some tasks, that you under-spend on others. In this way, you can control your spend and deliver under budget.


[widget id=”custom_html-68″]


Goal 3: To Meet the Requirements

The goal here is to meet the requirements that were set for the project at the start. Whether the requirements were to install a new IT system, build a bridge or implement new processes, your project needs to produce solutions which meet these requirements 100%.

The trick here is to make sure that you have a detailed enough set of requirements at the beginning. If they are ambiguous in any way, then what was initially seen as a small piece of work could become huge, taking up valuable time and resources to complete.


Goal 4: To Keep Customers Happy

You could finish your project on time, under budget and have met 100% of the requirements—but still have unhappy customers. This is usually because their expectations have changed since the project started and have not been properly managed.

To ensure that your project sponsor, customer and other stakeholders are happy at the end of your project, you need to manage their expectations carefully. Make sure you always keep them properly informed of progress. “Keep it real” by giving them a crystal clear view of progress to date. Let them voice their concerns or ideas regularly. Tell them upfront when you can’t deliver on time, or when a change needs to be made. Openness and honesty are always the best tools for setting customer expectations.


Goal 5: To Ensure a Happy Team

If you can do all of this with a happy team, then you’ll be more than willing to do it all again for the next project. And that’s how your staff will feel also. Staff satisfaction is critical to your project’s success.

So keep your team happy by rewarding and recognizing them for their successes. Assign them work that complements their strengths and conduct team building exercises to boost morale. With a happy motivated team, you can achieve anything!

And there you have it. The five goals you need to set yourself for every project.

Of course, you should always work smart to achieve these goals more easily.


Published on May 12, 2010.

The Fallacy of SMART Goals

I recently read a news story about how to keep our New Year’s resolutions. The article was about the use of simple time management techniques, the center of which was setting SMART goals. SMART is an acronym that’s been around for decades and stands for goals that are Specific, Measurable, Achievable Relevant, and Time-bound. Sometimes other words are used, such as assignable, realistic, timely, and testable.

It sounds good. It sounds useful. But simplifying time management into an acronym reduces the complexity of managing our projects to a seemingly simple formula, one that can prove frustrating. It reminds me of countless bosses and sponsors I’ve had who said, “Can’t you just tell me when the project will be done? Use SMART goals to help you figure it out!” Don’t get me wrong. I think this acronym is useful as a high-level framework. But if our goals too high-level, we run the risk of never achieving them. It’s just not that easy. Let me give you some examples using a project to build a house.


Specific. What does it mean to be specific? How are specific goals different from measurable or achievable or time-bound goals? In our house-building example house specifications are specific, as the name implies. There are specs for the exterior and the interior. Specs for landscaping, the roof, the plumbing, electrical and so forth. How specific do they need to be? Specs without detail might be helpful as an overview, but not for the actual construction of the house. We need to drill to down for the specs to be workable.


Measurable. To say that the house will be complete in 18 months, for example, is measurable. It’s a good starting point. As the homeowner I can start planning when to put my current house on the market or end my lease, when to get current utilities canceled and the new ones turned on, when to arrange for movers and so forth. But when is done really done? I’ve been told a house was done before the gas was hooked up. I was told a house was done, but movers wouldn’t unload their truck because the floors had been finished too recently. We need to get the detail to make important decisions. And as PMs we need to determine who will decide which measures to use and whether they make sense from a project perspective.


[widget id=”custom_html-68″]


Achievable. Achievable is another one of the squishy terms in the SMART acronym. It’s one of those words that means different things to different project stakeholders. I suspect I’m not the only PM to be told to “just make it happen.” Or “Where’s your can-do attitude?” I can certainly make almost any project happen, but at what cost? How much risk will the organization/sponsor/end users tolerate? Achieving an end quickly might mean making compromises. Who will make those decisions? What about trust and team dynamics? All these components of achievability need to be considered. And that takes time and lots of discussion.


Relevant. I’m not sure I understand what a relevant goal is. There are so many different stakeholders on our projects, some of whom do not find the project or its end product relevant at all. Hopefully it’s relevant to the organization, helping it meet its business objectives. But we all know that’s not always the case. I suspect many of us have worked on someone’s “pet project.” Or have had some stakeholder groups resist implementation. Or have managed projects highly relevant to end users but not to higher levels of management and vice versa. Getting agreement on what is relevant and how the project’s relevancy fits in with all the other projects is no easy task.


Time-bound. This usually means attaching a timeframe to the goal. I struggle with the difference between time-bound and all the other goals. I think they are intertwined. As a PM I worked on projects that were relevant only if they could be implemented in enough time to get goods from sourced locations to retail stores and on the shelves in time for the holiday season. Is that time-bound? Or relevant? Or I suspect, a bit of all the components of the acronym.

Which brings me to my original point. SMART goals are useful as a framework. But the key to time management success is going from a high-level overview to subsequently lower and lower levels of detail. We can certainly start with SMART. But we need to drill down to really achieve our goals.

Best of: How to Write a Smart Organizational Project Management Plan

Failed project planning can lead to failure even before starting the work on it.


But you can avoid the free expansion of its volume and inflation of the budget and achieve your goals. However, sitting down and planning the entire project is not as easy as it seems.
Usually, the next questions appear: how to predict how long it will take to complete tasks? How to turn the expectations of stakeholders into concrete results of work? What if something goes wrong? How to make an ideal project management plan?
We have collected the most efficient tips on how to create a successful project plan.


Start with TOR

The basis for a successful project plan is the terms of reference (TOR). Why? Because it helps to reach an agreement at the beginning of work. Later, when new requirements arise, and the scope of the project will begin to expand, it will be possible to return to the TOR and check what the plan was initially intended for.
The TOR should include a description of the goals and objectives of the project, its intermediate results, the definition of stages, a preliminary scope of work, the calculation of time and costs, as well as a general description of the roles and areas of responsibility in the team.


Set the timer

Gather stakeholders and team members and determine what you want to achieve and how you are going to do it.

Stage 1: Stakeholders. Write down who you should contact for help, information, or approval, and identify the project sponsor. If the list is too long, break it into primary and secondary participants.

Stage 2: Components. It is your work hierarchy. List all essential units of work and proposals (you will evaluate them later, but for now write it down). Limit the list to 30 points, and if team members try to add something else, round out and go to the next step.

Stage 3: goals and results. Write down the purpose of the project, then determine what its results should be. Check whether everything is correct by asking the question: “If we do everything that is indicated in stage 2, will we achieve our goals?”

Stage 4: possible alternatives. What are some alternative ways that will lead you to the same results? Is there a better way to achieve your goals?

Stage 5: economics and obstacles. What is the project financing strategy? How important is it compared to other projects? What resources do you need? What obstacles will you face?

Stage 6: plan of attack. Examine the list of units of work and determine what should be done first. Put the letter A at this point. In the same way, place B, C, etc. Then find out what can be done simultaneously with points A, B, etc. So you will make a project schedule.

Stage 7: assumptions and risks. What difficulties may be encountered in performing each task? How can you reduce risks or find workarounds?

Stage 8: key success indicators. Identify the 3-4 most important stakeholders and ask: “What is the most likely outcome to satisfy them?” These will be the indicators of project success. Decide how to measure each one after the project.

You can (and should) work on the project further to clarify the work plan, but in just an hour you will be able to draw up an entirely decent offensive plan: identify interested parties, define goals and determine project results.


[widget id=”custom_html-68″]


Do not complicate

Project plans can become cumbersome very quickly, especially when it comes to the opinions of stakeholders and sponsors. In order not to make matters even harder, we suggest you start with five questions that will create the foundation and give depth to the details of the plan.

  • What for? What are the main benefits of this project for business?
  • What? What is included in the scope of the project?
  • Who? What are the leading roles required for the “What” clause?
  • When? When is it necessary to complete the “What” clause to get the “Why”?
  • Where? Where is best to do the job? Where can “What” be used by customers and end users?

Only after you finish answering these questions, you can proceed to the answers to the question “How?”.

Best practices of project management planning

As you can see, there are different approaches to creating a project plan. There is no right way, but there is one technique with which all experienced managers agree: before embarking on a job, clarify the main goals of the project with the interested persons.
Another tip: before you start, hold an organizational meeting. Take the opportunity to explain to the team the goals of the project, the role, and areas of responsibility, set standards for successful work and choose a methodology and tools for project management.

One last thing: fix everything. Project progress notes will help you analyze your work and make smarter decisions.


Main components of the project management plan

What should be included in the project management plan? The carefully crafted project plan consists of the following elements:

  • Concept: answers to “what?” and “why?”. It is brief information about the design, goals and final results of the project.
  • Implementation strategy: Answers to “how?” Related to the project. What technique will you use? Will the result be issued at one time or in several stages?
  • The scope of work: what is included (and not involved) in your project? Describe here the hierarchical structure of the work and the main results.
  • Schedule: depending on how clearly your project is described, this can be either a general plan for the implementation of individual tasks or a detailed Gantt chart indicating milestones and deadlines for their completion.
  • Organizational structure: an overview of the hierarchy of the project team, roles and areas of responsibility. If several teams or divisions take part in the work on a project, it is necessary to indicate how these teams will work with each other, who should be considered as interested persons and who is responsible for achieving each result.

It may seem like a tremendous amount of information, but remember that this is only a sample of a project management plan. A good program will not necessarily include all these elements.
As successful managers point out, “An overly detailed plan will not make you smarter or more organized. The longer it is, the greater the chance that no one but you can finish reading it to the end.” A simple project plan that is convenient to follow is the best option.


Published on April 23, 2019