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.