The End Game

Do Projects Ever End Early?

Finally, after many years of thinking about it, my book, titled "Do Projects Ever End Early?" is ready to download.

Do Projects Ever End Early?

What is the book "Do Projects Ever End Early?" about?

As the sub-title says:

Or put another way:

Does work expand to fill up available time?

By Danny Schoemann

Doing. Making it happen. With a smile.

Come join me on a fascinating journey of what goes on behind the scenes in various companies. The various cultures and intrigues that cause projects to either deliver early or late.

We will meet over a dozen Project Managers who share their insights and experiences. Meet? Not really. I’ve never met any of them face-to-face. These are all members of the StackExchange Project Management community.

But each one has their own story to tell. Some are simply variations on a theme and others are diametrically opposed to their peers.

What we will learn is how these different approaches severely affect the progress and outcome of the projects their teams work on.

To help ensure that you cultivate the correct culture in your company to ensure the best results, most sections end with a paragraph titled Winning Teams, highlighting the possible lessons to be learnt.

You can download Do Projects Ever End Early? for free from this link.

What's the step after Project Manager?

After years as a Project Manager, managing projects of all sizes and shapes, I finally was given a job as Senior Project Manager.

What does the word Senior mean in Project Management? Senior Project Manager is usually defined as managing multiple projects, each with its own project managers. Coordinating resources and schedules between projects instead of managing the actual project.

Doing so involved a lot of coordination with management. Specifically preparing the agenda for the bi-weekly status meetings and then implementing the decisions.

These meetings included the CTO, the Chief Innovation Officer, the VP of Product other Senior Managers.

These C-Levels were getting their marching orders from upper management and the board of directors.

So what comes next? I've decided to learn how to become a member of the Board of Directors. To do so I enrolled in an intensive 12-week course at the Hebrew University.

We are learning about the responsibilities of the Board of Directors, how to analyse financial statements, and how to be an active member of the board by providing constructive criticism and novel ideas.

With my background in software development and cloud-based cyber-security, I see myself as being able to play an important role in ensuring that companies are implementing state-of-the-art security measures as well as comprehensive backups.

Even if I continue the exciting job of Project Management, I still think that this education is valuable. Understanding how the board functions and what their agenda is, (long-term planning and short-term stability), will help me focus as a Project Manager and make better decisions.

Perspectives: Parsha and Technical Spec

Based on an idea that my friend and mentor - Rav Micha Berger - posted on Aspaqlaria.

The bulk of the weekly Torah reading of this week and last week seem repetitive; details about various sacrifices. The difference?

Vayikra describes the sacrifice as performed by the person bringing it.

Tzav describes the sacrifice as performed by the priest, the Cohen.

These are two totally different perspectives: Like the MRD vs. the Tech Spec. The Customer vs. the Engineer. The User Interface and the Backend.

In a nutshell: The Technical Specification needs to include all the details the customer doesn't want to know about:

The Customer wants Users to log in to the system. The Spec has to define how a user can recover a lost password, change their password, and is MFA implemented and how.
The Customer wants the system to work. The spec has to define how to recover from unfinished transactions due to network trouble, and to save every detail of every transaction to enable tracing and debugging.
The Customer wants it to be device agnostic. The Spec has to define how it will look and behave on every device.

And the list goes on. Each person living life from their own perspective and the Project Manager who has to see and understand things from all perspectives.

Let the fire burn continuously

This week's Torah Portion is Tzav - where we learn about the Mitzvah to keep the fire on the Altar burning continuously. 24/7 as we would say.

The Mishna teaches us that the Cohanim - the priests in charge of the Temple service - were on duty from before dawn until way past sunset. During the festivals they sometimes started around midnight.

We all understand that live systems have to be available 24/7, or at least 24/6 depending on the user base.

To ensure round-the clock- coverage, the day is split into 3 or 4 shifts, often in appropriate time zones.

But, when deadlines loom, for some reason it's assumed that the same people can work around the clock. Or, at the very least, remain late and function as usual the next day.

My first such experience was in the 90's. We were preparing the Gold Disk; the Master CD that would be shipped to Ireland from which other CDs would be copied, put into boxes with their user manuals and shipped back to us. (All this with dinosaurs threatening to stomp through the factory.)

It had to be ready first thing the next morning, or else we were doomed.

We did an all-nighter. As the person who did the setups, I would get the latest build from engineering, run the setup scripts (which only included 2 manual steps) and inform QA that it was ready to be tested.

We were "ready to ship" before the sun rose. We were elated.

Until 2 days later. The first day, if any of us came (back) to work, it was after lunch time. Rare are those who can function properly after missing a night's sleep.

The next day, we were back, ready to celebrate properly, but QA started finding bugs. As Time went on, more and more issues were found and fixed.

End of story? We received a shipment of shrink-wrapped software that ended up as land-fill. We eventually prepared another Gold Disk after thorough testing - and we received a sellable shipment of shrink-wrapped software a few weeks behind schedule.

Since then I have been opposed to meeting deadlines by working after-hours.

How? You can find a clue by reading this question of mine on StackExchange's Project Management network, for example.

See no evil, do no evil

What's worse? Not keeping your promises or hiding information?

Vayikra Ch. 5 opens with various types of sins which have the same atonement. The first on the list is a witness who decides not to speak up, the last on the list is one who doesn't keep a promise.

The Torah equates these actions, at some level.

MBA - "Managing By walking Around" - is a favorite method of mine to get updates. Talking to the soldiers in the trenches yields better information than any other method.

Years ago I used to produce a Weekly Progress Report for the CTO, but it was mainly used by QA for planning the week ahead.

Frequently, when asking Team Leaders what their team was up to, I would get an incompatible answer to what I had heard from the individual team members. I quickly learnt to start from the bottom up, and would often update the Team Leaders as to the status of their team.

(Had I thought of continuing up the chain, to the C-Levels, the VPs and the board, maybe the company would still be around? Just wondering...)

Project Managers (or call us Program Managers or Product Managers) cannot over-communicate; share all the information you can. But don't miscommunicate; a result of not understanding the technology - another pet-peeve of mine that I have written about previously.

Taking responsibility

Vayikra discusses the various atonements for various sins.

If you err then you have to make amends. Nobody can do that for you.

With one exception: if the Sanhedrin - the highest Halachic authority - (similar to The Board) errs, then they bring an atonement for everybody who followed their erroneous ruling.

Wouldn't that be a better system than ours?

Project Managers collect all the requirements, hear various estimates and then define deliverables.

Too often, when something goes wrong, the team implementing has to suffer the extra work; the higher-ups simply re-assess the situation, raise red flags and set a new delivery date.

Even worse is when the entire concept was dictated from The Board. If it fails, it's not the board that loses its job, it's not the CEO who gets a cut in salary. Too often the testers and junior staff get pink-slipped.

The absurdity of firing the testers and juniors is lost on many:

- Firing staff that are finally trained, and will have to be replaced eventually. And the new staff will once again be trained and barely functional for the first few months. Hardly cost effective.

- The trivial reduction in budget compared to cutting a senior's salary. Most C-Levels executives earn 5 to 10 times what a tester or junior earns. But it sounds impressive when you fire 20% of the staff.

To be fair, I once worked at a place where the C-Level executives shrunk their salary drastically, for a few years, in an effort to save the company and the staff. But it's the exception, not the rule.

Birds are not narrow Animals - Mobiles are not narrow Desktops

Continuing through Vayikra; the weekly Torah reading:

There are 3 categories of sacrifices: Animals, Birds and Flour - each with its own method for sacrificing.

E.g.: An animal is slaughtered the same way it's slaughtered for your kosher butcher, whereas a bird being sacrificed is slaughtered in a way that would make it unkosher for regular consumption. A flour offering is not slaughtered - that step is skipped.

When preparing a Technical Spec, one cannot simply treat the Mobile Phones as a narrow-screen desktop. That creates ridiculous and cumbersome interfaces.

A mobile User Interface must be designed specifically for a mobile device.

I recently used an interface that worked very nicely on a desktop - with the top left-hand side being your profile and dashboard - very convenient. But on a mobile the top of the screen was always your profile - and you had to scroll down to get any work done.

That's what happens when you treat a mobile device as a narrow desktop.

And then you have the tablets - they cannot be ignored.

On a practical note, use a service like BrowserStack to see how your product looks on various devices and various browsers on those devices.

New Beginnings - New Concepts

The first in a series of posts highlighting Project Management concepts in the weekly Torah Reading.

This week, we start the 3rd of the 5 Books of Moses - Sefer Vayikra - וַיִּקְרָא .

The first thing one notices is that the first word - ויקרא - is written with a tiny א.

As the Ba'al HaTurim explains this was a result of the humility of our teacher Moses; not wanting to publicize the fact that Gcd was using a term of endearment, he prefered to make it look like he was being called like any commoner, with the term: ויקר

One of the secrets of a good Project Manager is humility; it's not about Project Management, it's about delivering a project on time.

Too often The Project Management becomes the main focus: attend the daily standup, create progress reports, and update your Jira tickets. The fact that the project is progressing on paper is what's important; irrelevant of the actual state of the end-product.

Similar to the cleaning staff, who, instead of ensuring the office is clean, turn the office experience into one of "Keep Our Office Clean" and turn everybody's focus to attaining the goal of zero-dirt.

A Project Manager's task is:

Ensure everybody knows what they are supposed to be doing right now.

What's the upcoming milestone and what is included in it.

Remove impediments that prevent them from concentrating on their jobs.

Are they waiting for feedback from somebody? for a License? For permissions to a system? For equipement?

Ensure that resources for future tasks are available.

E.g.: Design sign off, graphics, QA resources or licenses for add-ons.

A good Project Manager will ensure the focus is on delivering the project and not on the process, or, worse, the Project Management.

Quantum physics, coordination and removing impediments

Not everything is a "project", but there are other tasks that a PjM can do to move things along.

Some recent observations:

Observer Effect

Sometimes a "job"needs to be done, but is stalled. Simply assigning a PjM to the job can get the ball rolling.

Recently I was assigned to "get this job done". I had no idea what it was, but by the time I had gathered together a team on Slack, and the team added a few more necessary members, the task was done.

Simply getting the correct people to talk to each other was 90% of the job.

A while ago I took an orphan task that had started way before I started at the company. By simply asking where it's holding and what needs to be done, gave the actors the incentive to finish the task and roll it out.

Unclear what's at work here; maybe it's the Observer Effect - "Physicists have found that observation of quantum phenomena can actually change the measured results of this experiment."

Coordination

Sometimes a job - or even a project - requires multiple teams to work in serial. The handover from one team to the next is often stalled until a PjM steps up and makes it happen.

This is less apparent - and less needed - when teams work together; the coordination is built in at design time and during the kick-off stage.

Removing impediments

Removing impediments is another PjM speciality. A team may be stuck because they are missing equipment, or a 3rd party license or an outside contractor.

A PjM sometimes needs to step in, discover what is missing and then remove the impediment: go to finance to get the requirement purchased, or the CTO to get permission to hire a contractor. Barely Project management, but very necessary for getting things done.

"A meeting without minutes is a kumzitz"

"A meeting without minutes is a kumzitz"

- Danny Schoemann

What do you think of my new philosophy? How useful are meetings if nobody keeps track of what is being discussed, what the action items come up and without follow-up from the previous meeting?

Even when schedules and Kanbans are being updated in real-time during meetings, I still believe that meeting minutes are important, for example for those who aren't present or for historical perspective.

Solving Ransomware attacks with Project Management

Ransomware attack leads to shutdown of major U.S. pipeline

That was the headline that caught my attention this morning.

As a Project Manager, certain thoughts crossed my mind - using subconscious techniques like risk management, crisis control and borderline-use-cases:

1. All ransomware attackers want to be paid in cryptocurrency.

The whole world is suffering from a crackdown on grey & black-market currency. In Israel - for example - there's a limit as to the amount of cash you can pay when buying items. How come you have so much cash?

Every time I transfer money to one of my kids, I worry that some algorithm will flag it for some bored paper-pusher to investigate, and waste hours & days (and possibly lawyer fees) to prove my innocence.

Yet, you can squirrel away your criminal earnings into crypto and voila! life is good. No way to trace what you do with it. No way to trace you are you.

Clearly, it's time to change the anonymous aspect of crypto. (I'm a firm believer that only people with things to hide refuse to divulge information that would help solve international identity issues. From biometric identity documents to cryptocurrency, and more. But that's not the point I'm dealing with here.)

I'm not sure how to go about it, and I sure hope that law-enforcement agencies are working on this...

2. It's not the mouse, it's the hole that steals.

A somewhat amusing Talmudic statement - shifting the blame from the mouse (or hacker, in our case) to the hole.

So, how do we fix the hole? That's the cat & mouse game (pun intended) that half the world is playing against the hackers.

But, if one can mitigate the affects, to the point where one doesn't even consider paying the ransom, one has shrunk the hole tremendously.

Here are some ideas for mitigating the pain of a ransomware attack, based on being responsible, inter alia, for IT and DevOps for the past 9 years.

A. Backups

Duh. Don't you have anything to write about? Well, let's reword that to backups and fast restores.

I refuse to believe that something as crucial as a U.S. gas pipeline supplying the entire East Coast does not have backups in place. But... if they cannot restore in a timely fashion, then they will have to work with a crippled system for a while.

This is unacceptable. The smallest Mom & Pop shop will suffer from a few days down-time. The more critical the computer system, the less it can afford down-time. So it's crucial that the backups are:

Actually happening - and not suffering from out-of-space or limited bandwidth issues, or other excuses.
Up to date - you don't want to lose more than a few hours (or minutes) of work.
Fast restore - the closer to instant restore, the better.
Ransomware-safe. If the backups are hacked, or you are backing up a system with the ransomware attack installed, you essentially don't have a useable backup.

Let's discuss these last 2 points in more detail.

Fast restore

As already mentioned, if you cannot restore in a timely fashion, you are going to be without the ability to function; from being unable to sell lollipops to having patients dying.

One technique I came across was to virtualize everything - then the machines can be backed up periodically by taking a snapshot. This technique is used on VMWare servers, for example, and is easy to automate, doesn't require downtime (you can backup while working) and the restore is almost instant.

I've also used offline-continuous-backups like Carbonite; the restore can take a while, depending on your bandwidth. Your apps won't be restored - you'll have to reinstall them - but your data will be almost up-to-date.

Ransomware safe

You have to ensure that you have a backup from before the system became infected with ransomware. Otherwise, the ransomware will attack again once everything is fully installed.

A rotation of 7-daily and a few weekly backups is one way to ensure you will have a clean restore point. Yes, it will take up a LOT of disk space; but, hey, disk space is almost free nowadays. Compare $800 for a 20TB disk to 1 BTC (1 Bitcoin is North of US$57,000 - yes, fifty-seven-thousand dollars).

That's 70 external disks of 20TB each.

Make sure you have on-site copies - for quick restores - but make sure they are off-line, or else ransomware will destroy them too. Yes, this requires frequent manual intervention, but is well worth it.

Do yourself a favour and keep off-site copies (like in AWS S3) for off-site security. (Good in case if fires, thefts or ransomware to note a few possibilities.)

Mirror, mirror on the wall

After many decades in Hi-Tech, few work-relate incidents stand out in my memory as starkly as those days that I got to work and my computer was dead.

Walk over to Tech Support (since you cannot email without a computer - and in the olden days we didn't have smartphones; they hadn't been invented yet) and after hours of walking around aimlessly you can start working again.

Well, not really, you have to reconstruct your work environment, reinstall your favorite apps, map your favorite drives, etc.

All this changed about 9 years ago when I became responsible for IT. Who does IT go to when they need IT? Who cuts the barber's hair? Who does a dentist go to if he has a toothache?

What I did was to take an older machine and - one that was too old & slow for normal work - and install everything I needed on it. Every time I installed a new program I would install it on my mirror-machine too.

The rest of the time the mirror-machine was powered off. (This created an interesting question when we were audited for licenses.)

When the dreaded day arrived, I had to deal with reviving my laptop . But I could continue working - I just powered up my mirror-machine and everything was there, as I liked it.

This got me thinking. Why don't hospitals, government offices and everybody else who has mission critical computers have a mirror system in place?

Then when the ransomware attack happens, or flood, or fire or theft, everybody uses their mirror-machines. Of course, you would need to be careful not to infect the mirrors - possibly having them on their own network - and maybe in a separate room/building.

The devil in the in the details, but I want to raise the awareness of these possibilities.

Mix & Match

Now imagine if you would virtualize all your machines and restore them frequently to mirror-machines.

Then in an emergency you would have an almost up-to-date useable system, with minor down time.

Eureka

Thinking though the details and what I should include to keep this a manageable size, I realized that I may have a possibility for a business.

Anybody want to join me? Creating a system implement and automate the mirror-backup system? Or maybe off-site locations to instantly relocate to in times of system failure?

I no longer want to start the day with headlines about impeding catastrophe because of ransomware.

An amazing discovery - the 12 Factor App

I have a daily reminder that pops up and reminds me to write something on this blog.

As you can see, I have not been persuaded nor inspired nor had enough free time to do so.

But today I discovered The Twelve Factor App - and I'm excited enough to want to share it - and document it so that I don't lose track of it.

For example, it seems that I'm not the only one who treats things like Version Control as a crucial part of development.

Yes, I know, some of you will be aghast at the thought that this isn't always so. Others will wonder what that is.

12 years ago I promised that "In a future post we'll discuss why you never want to allow your project to proceed without some form of Version Control" - looks like I'm in good company.

In a nutshell, the 12 factors - copied from their site - are: