Skip to main content

Tag: Requirements

Working Hard, But Not Too Hard!

Working hard is applying a high level of effort, being consistently focused, productive and effective, applying emotional, physical, and intellectual energy. Working hard is rewarding, it leads to personal and organizational success.

Some people say, “Work smarter, not harder.” But working hard is not the opposite of working smart. The two go together. Working smart makes working hard more effective. Working hard without working smart leads to working too hard.

Working “too hard” causes fatigue and burn out, it reduces performance, challenges relationships, creates a cycle of emotional reactions like anger and depression. Challenging work becomes too hard when it can’t be sustained. Sustained challenging work, physical or mental, requires sufficient reward, rest, relaxation, and recovery.



What does it mean to work “too hard”? With two people doing the same work, one might find it too hard and the other too easy.

Some years ago, I managed a project that had a tight time deadline (don’t they all?). We were a core team of six people including myself, all in our late 20’s to early 30’s. For the last month of the project, we were working late into the night, coming in early in the morning, and occasionally doing all night work sessions. We had pretty much cut off our social and family connections for the duration. The work was engaging, state of the art, and creative. The reward was both financially, emotionally, and intellectually rewarding. Team members had bonded, and it often felt as if we were reading one another’s thoughts. We were in Flow. When the project ended, we were both ready for a rest and sad that it was over.

Some family members and friends thought we were working too hard. For us it was a thrilling ride. It’s very subjective. Observers may or may not have an accurate perception of how hard a worker is working in any role as a performer, manager, or executive.


Objective Criteria

We can bring some useful objectivity to the question of what working too hard means by defining the characteristic conditions of “too hard”, to overwork, really means.

Working too hard means there is imbalance among the factors – hours worked, rest and recovery, task complexity, competency, work environment, relationships, mental attitude, and physical condition.


[widget id=”custom_html-68″]



Overwork is a principal cause of burnout. In my article Burnout: What It Is and How to Avoid it,[1] I identified the symptoms of – “exhaustion, disengagement, and reduced effectiveness.

  • Exhaustion is loss of energy and fatigue. It occurs when there is too much stress caused by unhealthy performance demands (chronic overwork). It can be a short-term experience following an intensive physical, emotional, or mental activity. Short-term exhaustion can be treated by moderating performance demands and taking rest and recovery time. If it goes untreated and becomes chronic, burnout follows.
  • Disengagement is affected by a sense of not being cared for by leadership and of the futility of the work. People lose a psychological connection to their work. Involvement and enthusiasm suffer. Performers, whether executives, managers, or staff, just put in their time instead of being actively engaged in their work. self-worth suffers. They become cynical and either engage in unnecessary conflict or withdraw to avoid engaging in meaningful debates.
  • Reduced effectiveness is tied to both exhaustion and lack of engagement. With tiredness, less involvement and enthusiasm, performers become less productive and less effective. That results in greater stress as performance goals become more difficult to achieve. Greater stress feeds exhaustion and lack of engagement.”

For observers, becoming disengaged with friends and family is perceived as a symptom of overwork. It may be, depending on how persistent it is, and whether overwork is the cause or work is being used as an escape from challenging relationships.

Symptoms are the most objective criteria available. It is up to each of us to be aware of our feelings and energy levels to decide if we are experiencing the symptoms of overwork.



“Self-awareness is the ability to “step back” and observe yourself objectively to know your behavior, motivations, feelings, values, and desires. It is knowing your personality and the way you display it in your life.”[2]

Your self-awareness enables you to see whether you are working too hard and if you are, why you are doing it.


Doing Something About It

You can do three things about working too hard. 1) You can avoid it, 2) you can correct the imbalance among hours worked, rest and recovery, task complexity, competency, work environment, relationships, mental attitude, and physical condition to stop doing it, or 3) you can continue and suffer the consequences.

You avoid it by establishing a healthy work-life balance. You stop it by identifying the imbalance and correcting it by adjusting your attitude and behavior.


For example, you can balance rest and recovery with working on challenging work for long hours, and intensively. That kind of work is often necessary and can be sustained if there is time for rest and recovery.

A supportive work environment, with space for quiet time, and workspaces designed for the kind of work being performed to provide comfort and ease enables breaks and eliminates unnecessary stress.

Healthy relationships, including the ability to manage conflict and expectations, remove unnecessary stress and enable intensive effort.


Mental attitude is a key factor. If you believe you are working to hard, you will act as if you were. If you believe that you are working hard and are ok with it, you will be most effective.

If your personal situation is creating the imbalance because of workaholism or anxiety about not working hard enough, you are faced with the task of addressing these causes.


If your work situation does not give you the ability to improve imbalance, you are faced with the challenge of making the changes that will protect your health and effectiveness. That may mean taking the risks of standing up to your boss and changing jobs.


[2] Pitagorsky, George, “Self-Awareness a Critical Capability for Project Managers”,

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.

The Courage to Try Something Old – Use Cases

There are many articles about project management trends for 2023. Among the common threads are a focus on AI and more automated PM tools. There are also contradictory trends like workers returning to the office or continuing to work from home. What I find most interesting, though, is that many of the trends have been around for years—like change management, agile and hybrid development methods, and focusing on benefits.[i] Does that mean that these old horses are not really trends? Not at all. It means that even when these techniques are out of favor, they are needed to successfully manage our projects.


One “old” trend I was happy to see was entitled Use Cases Are Back.[ii] Not that they’ve ever gone away. They’ve had different formats and names, like the Given, When, Then format, but the thought processes needed to develop a use case model have always been required.

To review, a use case is a model that describes how stakeholders want to use pretty much anything that’s being built, like a car, an elevator, a phone app, or a change to an existing system. But defining them is not easy. We can’t just ask our stakeholders how they would like to use a microwave or what functionality is needed in a sales app. We need to ask the right questions. And a use case model is a great tool for getting at those requirements.

A use case model, like almost all models, has both a graphical and textual component.[iii] The first component, a use case diagram, is a picture of the how the stakeholders will interact with what’s being developed. It identifies all stakeholder groups who will use the end product and how they want to use it. It also describes all the systems and other components needed to make it work. It becomes a picture of all the people and technical components, as well as all the functionality needed to make it useable. And it’s a great picture of the scope of the effort.


Some PMs and BAs have trouble getting started, so I have developed 5 business questions that can provide a jumpstart in the creation of a use case diagram.

Use Case Diagram Questions

  1. What’s being built? It’s usually called a system, but we can call it whatever we want. Examples include a new car, a change to an order system, and kitchen cabinets.
  2. Who are the stakeholders who will use this system? These are often called actors, such as an auto service consultant, a consumer, and cabinet designer.
  3. How do these stakeholders want to use the system? What functionality do they need? These are the use cases themselves. They are stated as high-level processes, like Start Car, Order Product, Measure Cabinets.
  4. What other systems or components will interact directly with the system? These are also commonly called actors, like Ignition system, Replenishment system, and Cabinet Delivery Schedule system.
  5. How will the actors and the system talk to each other? These eventually become the user interfaces that allow the system to recognize what the actor wants to do. The driver sends some signal to the Start Car use case. A consumer enters an item into Order Product use case. A cabinet designer enters measurements into a design cabinet use case.

The textual component is known as a use case narrative or scenario. It describes the process steps which detail the interaction between the stakeholders and what’s being built.


[widget id=”custom_html-68″]


For example, how do we start the car? Does the driver put a key into the ignition? Press a button? Does the car start when the car phone app is connected and the driver opens the door? Something else? There is no one right answer. But the questions below will help our stakeholders go through the required thought processes.

Use Case Scenario Questions:

  1. How do I know where to begin? Preconditions provide the answer. They tell us where to begin by describing what has already occurred. In our example, do I already have my keys? Have I already unlocked the car? Adjusted the mirrors? More preconditions mean that the use case scenario will be shorter and there will be fewer different paths. For example, if a precondition is that I have my keys, we don’t need to document what happens when I’ve lost my keys in this scenario.
  2. How do I know when I’m done? These are the postconditions. We stop when we reach these conditions. The pre and post conditions form the scope of the use case because they define what’s in and out of each one.
  3. What is the most common way of getting from the pre to the post condition? This is the “happy path.” There are no decisions in this path, such as what happens if the car won’t start.
  4. What are other ways of getting from the pre to the postcondition? These are the alternate paths. The car starts, but it takes three tries.
  5. What prevents us from getting to the postcondition? These are the exception paths, like when the battery is dead.

Use case models are extremely useful for getting the requirements of the interaction between stakeholders and what’s being built. There are other ways of getting them, but the structure of the use case can help us focus on what questions to ask and ultimately saves time and frustration.

[i]; are two examples.
[iii] I’m not including a use case diagram because of the many different conventions used. What’s important are the thought processes, not the conventions.

Best of PMTimes: The Why What and When of a Decision Log

Can you relate to that project that feels like it has been dragging on a little too long?


Moreover, your team is sitting in a conference room drowsy from preparing the final touches when one perky creative soul, who by the way missed the first four months of meetings (thus why they are perky), pops up with a question ‘Why are we doing it this way? We should look at a different option?’

Once the collective groans subside, everyone starts in on a chatter contemplating a different option. “Wait,” you think, “it has already been hashed out!” Quick, where are your notes? Where is that email talking about a different option? Was it in the meeting minutes somewhere? “When was that again? February?” This is all too familiar. You can’t quickly find the results, and you desperately want to stop all of the cross-conversation and new found excitement that has roused up the room. Then you sit back and remember, “Ah yes, I have a decision log!” You swiftly scan it, find the related item and pound your gavel on the table to gain everyone’s attention. It will all be fine, we are on the right track, and we don’t need to spend another moment of discussion because it was already agreed which would be the best action. Phew!


Utilizing a Decision Log, which is a list of critical decisions agreed upon throughout the project, has not yet leaped into mainstream project management practice, although it has started to gain traction being viewed as beneficial for recording impactful decisions and serving as a central repository for those decisions.

Why Do It?

The concept is a simple one. Once a discussion begins regarding a project, decisions are being made with some decisions essential for the direction of the project. Documenting those in a central location can be of value throughout the project as a quick reference and communication tool to assure everyone is aware of the direction.

Decisions may not always be agreed upon by the team members. Rather than opening a discussion for debate each time the topic arises, it is better to resort to the documented decision and move on from the topic.


Additionally, these decisions may be made in a forum that does not involve all team members, and they may be hidden in meeting minutes or informal email messages. Providing a standard method to document and communicate decisions can assure everyone is aware, avoid lack of clarification, and can be used as a method to focus team members when debate arises.

Decisions can be revisited when necessary, and may even be changed when new information presents to the project. Team members who raise valid points that counter a decision should be heard and their opinion valued as it may offer a better course of action.


[widget id=”custom_html-68″]


What Information to Include?

A decision log is a beneficial communication tool to assure all stakeholders are apprised of how a decision was reached, what other options were considered, and who is accountable for the decision. It provides guidance to the team members and can eliminate potential confusion. The format you use may be a spreadsheet, automated log, or another method that suits your environment.

The primary information to capture includes What is the decision, When was it made, Why it was made, and Who made it. Other information may be captured as well and may vary based on the project needs.


When to Include a Decision?

When to include an item in the log involves striking a balance between what is valuable to have recorded versus what is too detailed, and will take thought. As well as considering the overall audience, team members and project dynamics also consider these things:

  • Topics that are frequently debated or where there is often disagreement.
  • Decisions that may be confusing or not clear to all stakeholders.
  • Those made that impact the direction or future work of the project.
  • When alternatives exist, but only one must be selected.
  • Decisions made by leaders, or others outside of the project team, which will impact the work of those team members.
  • Those that impact what or how a deliverable will be achieved where it may be different than some stakeholders expect.
  • Items that may not seem significant but can cause issues if not understood.

As a project manager, you must judge what your stakeholders will view as too much detail. You also must consider not eliminating items that you think are valuable to minimize detail.


There you have it!

No one wants more documentation. That goes for the individual who must create and maintain it as well as the recipients who do not want yet another attachment to read. The value of the log is for the project manager to have a centralized location to capture items that may cause debate or slow progress or for those who are included to search for information on the project materials instead of hunting down the project manager. This can turn into a time-saver and worth a try it on your next endeavor!


Published on January 23, 2017.

Practical Perfectionism and Continuous Improvement

“One of the basic rules of the universe is that nothing is perfect. Perfection simply doesn’t exist…..Without imperfection, neither you nor I would exist” ― Stephen Hawking


“Continuous improvement is better than delayed perfection.” Mark Twain


Practical perfectionists use the urge for perfection as fuel for achieving it, accepting that while things could be better, they may never be perfect.

Practical perfectionism is at the root of quality improvement. We set standards and try to meet them with the goal of optimal performance – performing as best we can. We recognize that optimal performance is perfection even though there may be flaws, errors, and omissions.



Sometimes things are perfect as they are:

  • People are happy, effective, accepting, flexible and resilient
  • Change and problems are well managed
  • Communication and relationships are healthy
  • Performance quality is high, and
  • There is a continuous improvement process that asks “How can we do better?”

In that ideal scenario the stakeholders are aware that everything is in motion, continuously changing. They know that expecting to sustain a static perfect state is a pipe dream – an unattainable hope. They know that perfection is in the process and not the outcome.  They strive for the perfect outcome even though they know it may not be attainable.


The word perfect is an adjective and verb. We perfect our process to make it perfect. According to Merriam-Webster the meaning of perfect is:

“Being entirely without fault or defect flawless. a perfect diamond. : satisfying all requirements : accurate. : corresponding to an ideal standard or abstract concept. a perfect gentleman.”



Perfectionism is a character trait that can be healthy, positive, and functional or unhealthy negative, and dysfunctional. It is a need to have oneself, others, or things in general to be perfect. There is an uncomfortable felt sense, a pressure from within, when things are not perfect. There is a belief that perfection is possible and necessary.

Perfectionists set standards that they use to judge their own behavior, and the behavior of others. They assume that others expect them to meet those self-set standards.

When perfectionism operates unconsciously it gets in the way of optimal performance. For example, it can manifest as procrastination because things are not perfectly ready. “I can’t get started until I am absolutely sure that I won’t be interrupted.” Some perfectionists procrastinate or avoid acting because they fear that their work will not be perfect.


Perfectionism may emerge as a negative self-image or image of others because they are not perfect.

For example, a project sponsor keeps putting off the funding of a project because the design team cannot find the perfect solution or the selection of a key product or system is held up because there are  no perfect options.

The expectation that a team’s or individual’s performance be perfect can motivate high performance or, if the expectations are impossible to meet, over-stress and demotivate.


[widget id=”custom_html-68″]


Striving and Concerns

Perfectionists strive to achieve personal standards that they set themselves and are concerned that they won’t measure up. The striving may be focused on both themselves and others.

They worry and fear that they will be punished or rejected if they fail to be perfect in the eyes of others – their boss, client, peers, etc. They tend to promote the impression of their own perfection and work to prevent others having a negative impression.

The striving and concerns, when they are unconsciously driven, waste energy and create stress, the enemies of optimal performance.



Non-perfectionists tend not to have pre-stated standards or expectations about themselves or others. Non-perfectionists are OK with whatever happens. While this leaves them with less stress and may even be a sign of enlightenment, it does not promote continuous performance improvement.

Acceptance is a positive trait, but it can also lead to stagnation and the degradation of performance. Healthy acceptance accepts things are as they are in the moment, that they will change, and that with effort they can be made better into the future.


Practical Perfectionists

Practical perfectionism involves setting rational performance standards and expectations and generating the motivation to achieve them. It is an example of how we can use a character trait to its best advantage.

It begins with the acknowledgement that perfectionism is at work. This is an aspect of self-awareness, the sense of what is happening internally and how it is influencing behavior.

With that awareness, perfectionism can be used as a powerful force in optimizing performance and promoting personal growth, emotional intelligence, and wellness. Perfectionism is accepted and managed.


Practical perfectionists have ambitious standards and bring rational thinking to bear. They assess why they think their standards and expectations are realistic. They look at the costs and benefits of improvement and decide whether to improve radically or incrementally, or to leave well enough alone, making the best of the situation.

Perfectionism is a positive trait if it is moderated by acceptance of things as they are, self-awareness, rational thinking, and realistic understanding of

  • what ‘perfect’ means,
  • whether and how it can be achieved,
  • how much it costs,
  • how long it takes to achieve it, and
  • whether achieving it is worth the time and effort.

Practical perfectionism drives continuous improvement and optimal performance.


Overcoming Obstacles to Perfect Performance

It is hard to imagine why anyone would not embrace a practical perfectionist mindset. But the reality is that there is resistance to self-awareness and rational thinking.

Overcoming obstacles to applying practical perfectionism to continuous improvement begins with self-awareness and understanding among team members and leadership at all levels..

When individuals realize that they are being overly stressed by their own perfectionism or are overly stressing others by expecting the impossible, they can act to change.


In projects the change comes about when perfectionist managers or clients realize that their expectations are irrational and counterproductive. Then the process of defining goals, acceptance standards, value, costs, risks, and benefits will lead to expectations that can be met.

Practical perfectionism combines emotional intelligence and analytical process thinking to promote a perfect process.