Risk Assessment after Hurricane Irene

Now that Hurricane Irene is behind us, and you've used your Crisis Control skills to salvage as much as possible in real-time, there's a natural urge to start Risk Assessment for the next natural disaster.

However, we cannot predict what the next surprise will be, since then it won't be a surprise. It's even harder to predict how much damage it will cause; nobody could predict the disaster and chaos caused by 9/11 - probably not even the terrorists who masterminded it - including Bin Laden himself.

Most of the time the size of the catastrophe is inversly proportional to the amount of preparation for it.

The trick is to break down the various troubles from the current disaster and group them into distinct categories. Each category then gets treated separately - and each category can be assessed for future prevention, if the risk/cost ratio is high enough. 

Here are some potential groupings - feel free to classify them differently.

• Communication
• Internet connectivity
• Access to our web site
• Access to our email
• Access to our customer support system
• Phone connectivity
• Mobile phones
• Land-lines
• Inter-office communication
• List of key people's home phones
• List of team-leaders contact info
• Escalation plan for:
• Emergencies
• Helping each other
• Moral Support
• Access to office
• Physical access
• Emergency exits
• Virtual access to email
• Access to sensitive info like passwords
• Backup and Restore
• Web sites
• emails
• Personal PCs
• Off-site backup
• Faster Restore

Each item on the list then needs to be taken care of. There are few - if any - generic solutions.

Let's work through the first item on our list: Access to our web site.

During the storm, our web site may have been inaccessible either because the electricity went out, or the internet connection died or the site was overloaded because of too many home-bound people trying to access it.

If our web site went offline during the storm, then we may want to have it hosted in more than one location. Unless it's a web site for the local population, and if the power to the web site goes down, then our entire user base cannot access it either, so there would be no need to be online.

• This highlights why the disaster control plans need to be updated periodically. Nowadays that mobile phones are everywhere, the above presumption is no longer valid. There maybe no electricity or internet within 100 miles of your user base, but you can be 100% sure that many - if not most - of your users will be online from their mobiles, hand-helds, iPads, iPods and other wireless technology.

But simply deciding on distributing your internet hosting is not enough. It needs to be implemented. If your system was not designed for being hosted at multiple sites, this could be a major project. At some stage, management will have to make a decision. To help them, you want to have figures of:

• The cost of damage to our reputation and traffic by remaining at a single site if it becomes unavailable for a day / week / month.
• There's also the cumulative cost, of people never coming back to a site that was down for more than a few moments.
• The monthly financial cost of hosting at 2 or more sites.
• The cost of maintaining more than one site for both engineering, QA and IT.
•  The cost of the design,  engineering and testing efforts required to upgrade the system. 

A final decision point to take into consideration is that the other site chosen may also be targeted by the next disaster.

When the Eyjafjallajokul volcano erupted, it caused airports all over Europe to be closed. Had your emergency flight plan called for racing across the continent from Belgium to Italy to catch a flight, it would have been useless as a backup plan.

Hurricane Irene proved that the 500 miles between NC and CT are not enough when doing hurricane Risk Assessment. An elementary understanding of weather patterns, the national electricity grids and the internet backbone would be required to decide on the safest location for hosting the mirror site.

If the decision is taken to implement the dual-location of the web site, then the implementation has to be tested to ensure that if either site goes down, then the other site will manage to run solo. It has to be able to handle the load; not only double the regular load, but maybe double of that, since during emergencies the site tends to get more traffic, either because it has useful information, or entertains those who are home-bound due to the circumstances, or maybe because the competition was not prepared to implement multi-site hosting.

Side benefit: Once we have multi-site hosting for out web site, maybe we can use it for other items on the list:

• Email access
• Lists of passwords and phone numbers
• Escalation plan
• Customer support
• Off-site backups

But don't assume that any of these solutions are trivial; you have to take into account issues such as security and access control when sensitive information is made available online.

In conclusion, identifying the trouble spots is only the first task. At some level it's the easiest one. Implementing solutions is harder. In future posts maybe we'll analyse what needs to be done for other items on the list.

Risk Assessment and Crisis Control are full time jobs; and the more time you spend on them, the more you'll be prepared for the next surprise that nature or mankind will spring at you.

- Danny Schoemann

Give credit where credit is due

Typical amateurish management attitude: It's his job, after all. Why does he also need a pat in the back? He gets a salary!


Giving people credit and compliments makes them feel good. People who feel good work better. So the more opportunities you find for complimenting your team, the more you gain.


That's besides the moral aspect; true they are being paid, but if they achieved something they deserve the credit.


Credits can be given in many ways:

• The "about" section can list all the team players; keep it alphabetic to avoid upsetting people.
• Patent applications can list all those involved, even if their idea didn't make the final cut.
• Progress reports can highlight those people who made a difference; rotate the names regularly to have everybody included.
• At company meetings make sure to mention a few people by name.

But beware of adding a prize to the credit:

• If it's not substantial, then it may have the opposite affect:
• After all those extra late nights all I got was a meal for 2?
• It can create internal competition - something we'll discuss in a future post. 
• It can put a monetary value on effort and people will start comparing their effort to their prizes and invariably you will get some unhappy campers.
• When finances get tight the first thing to go will be the prizes; and that's the time you need the most goodwill from your team.

Even sending out a company-wide "Happy Birthday" note to the daily celebrants is a way to make them feel special. If this comes with a birthday gift, then make sure that everybody (in a 6 - 9 months period, if not a full year), get the identical gift.

Another way of giving credit, saying thank you and making every feel appreciated is to occasionally give out freebies. Company T-shirts, pens and other give-aways can do the trick. If you order them for clients or fairs then order enough to also give one to each employee.

Celebrating major milestones or releases is another way to say Thank You to the teams involved. Ordering a cake or having some fun time with some games / quizzes or similar will cost the company 2 - 3 hours and will create the goodwill you need to start the next project with new energy.

Giving credit for non-job related tasks is also effective. Be it for somebody who keeps the coffee area clean or who starts an internal book club or even for somebody who did something outstanding in their private life.

Even though it's not work related, the person deserves a round of applause, and it will make them and their friends feel better - and they will all have a more productive day.

On the other hand, don't overdo it. Sending out a company-wide Bravo email when somebody does a 2 hour fix, is silly and shows that you don't understand the effort that goes into the bigger tasks. If you feel that a particular minor job was well done, then email that person - and her boss - but not the entire company.

Give credit where credit is due, and your team will respond by giving you lots of opportunities to give them credit. It's a win-win deal.

- Danny Schoemann

Generic - too much of a good thing?

There's a delicate balance required between making code generic on the one hand, and hard coding everything on the other hand.


Making the code generic can make it easier to tweak things.


For example, if your footer includes a copyright and the year, then you can either hard code the year, and change it every January, or you can write some code to calculate the year, or you can have the code retrieve the year from some properties file.


Here the solution seems obvious; write some code to calculate the year, and never worry about it again. However, debugging this code may be more time consuming than a yearly trivial update.


If you want to be able to control the amount of ads on each section of the page, it's easiest to control this from a properties file. Then you do not need an engineer to update the code!


This seems obvious, but not always feasible. Sometimes the ads have some business logic behind them that would require huge amounts of code to handle a generic solution.


Another problem could be error handling. Do you assume the values entered in the properties file will always be there and will always be correct? What happens if somebody enters a capital-Oh instead of a Zero? (Is this 2O or 20?)


Adding error handling has its own challenges. If the values are wrong, what values do you use? Who does the code inform and how? (You cannot show an error on the page; imagine thousand of users seeing "Bill, there's an error in the x value". Chances are that everybody but Bill will see this.)


In the mid-1990's setups went from being written in Microsoft's Setup-Basic to becoming sophisticated in order to handle the requirements of Windows-95; uninstall.


Since we created a new SKU almost daily, it made sense to create the new setup system as generically as possible.


The result was the following:

• A code base that was too big for the debugger; so we could no longer "see" what the program was doing, and finding bugs became really difficult. This was because retrieving each value from a properties file requires many lines of code, to ensure it was fail-safe.
  
  
• A properties file that was over 1,000 lines long. That's a lot of control over the minor details! But it's also impossible to control; fine tuning setups via the properties file was very tricky and error-prone.
  
  
• Since Product Management and Marketing were very creative, they demanded new twists we had not thought of. Once they would decide on a 3rd party disk we should install, another time they added a registration screen and then it would be a registration code or a "time limited" edition. Each of these great ideas required writing new generic code and adding more lines to our properties file.
  
  
• Once we had the templates for all our products, setups for similar SKU's became trivial. Adding or removing a language was easy. The engineers in certain groups took care of the own setups.

As Project Manager, I always ask the engineers to write code keeping in mind that it may be need to be changed regularly. 

• If it's something we know we want to test all the time, (like the number and placement of ads) then it should go into a properties file. 
• If it's something we will tweak once or twice (like a font size or color, and an experimental object that we want to test and either keep or discard) then it should be easy to find and easy to change. Don't make this particular object dependent on others, don't make other object depend on it - and put some comment in the code to make it easy to locate, even in 6 months time when you no longer remember the code.

This creates some balance between the joys and pains of being generic and being hard coded.

And this is another example of the advantages of having Project Managers who used to be techies.

- Danny Schoemann

Prototype pitfalls

In software, a prototype seems to work like the finished product. In reality it's usually a pretty face (GUI) with minimal functionality.


If you actually try use the prototype you will discover that it only works for a limited set of actions, if at all.


My first introduction to a prototype was in the mid-1990's. My good friend Jack Kustanowitz arrived at Kivun (of Dagesh fame) as a summer intern. 


Netscape had just released the first Web Browser - and all you could do was browse. Maybe it also had a back button that went to the previous page.


Using Visual Basic, Jack created a prototype of WebTamer; everything your browser needed. Functionality like "History", "Off line browsing" and "Bookmarks".


And it seemed to work! Making a product out of it should be trivial, Project Management was assured. (These were the same non-techie Project Managers from yesterday.)


Suffice it to say that the road from Prototype to Release was long and painful, since the prototype was mainly a GUI; a pretty face, and Jack-the-wiz-kid was back in college.


Prototypes of the graphical interface are easy to create, very impressive and very misleading to Project Management - and Management in general. It's hard to see why a product which looks ready-to-use will need months of development before it can be shipped.


Sometimes a prototype is used as a technical proof-of-concept. Being unsure of the capabilities and limits of certain technologies, a team will implement some functionality with technology they have never used before. Usually some new emerging technology. 


They can then measure:

• How long did it take? Does this seems like a faster way to implement features?
• How stable is it? If we stress the application does it crash or slow down?
• How fast is it? If they implemented existing functionality, they can benchmark it to see if it's faster or slower than the existing implementation.

In this type of prototype, the important functionality will be there, but the GUI may be missing. 

Can the prototype code be used in the end product? Sometimes; often it cannot as the prototype will have been done without a technical design;  that crucial design stage that ensures that multiple programmers can safely and efficiently work on the same code.

What a Project Manager needs to realize is that prototypes - both types -  are not an indication of a finished product, no matter how good the demo looks or functions.

The connection between a prototype and the end product is often similar to the connection between an ad and the actual product, or the trailer of a movie and the actual movie. You've been shown the highlights; the devil is in the details.

Lessons learned:

Having a "working prototype" will not in any way shrink the schedule. "It's almost ready" is not true.

A prototype does not absolve the Project Manager from creating a fully blow functional specification document. Assume all the functionality is missing. What you see in not what you will get.

Why a technical Project Manager?

Is it important that a project manager understand the technicalities of the project she is managing?


In theory Project Management is all about scheduling; finding out what needs to be done, how long it will take, and tracking the results.


There seems to be no reason why the Project Manager needs to understand the technicalities of the project.


I have discovered that this is not so. A Project Manager who does not understand the technicalities, has no idea what she is doing.


Firstly, the team loses all respect for a Project Manager who cannot differentiate between a check-in, a compile and a debug session. As a result they have no problem hiding information from the Project Manager - a guaranteed recipe for disaster.


Many years ago, before I became a Project Manager, I attended the daily meetings of a project, as manager of setups (the installation program).


In the engineering department I was hearing them talking about rewriting the Kernel - that's a huge job and is like a heart transplant.


In the daily meetings I was hearing the engineers inform the Project Manager that the project will ship on time - a few days hence.


Six months later the project was almost ready to ship, and I was convinced that I wanted to become a Technical Project Manager.


Had the Project Manager been technical, she could have asked what the team is up to, and understood that rewriting the kernel is going to be a long task.


Another reason for a Project Manager to understand what technologies are being used and what they do, is in order to catch inconsistencies as early as possible. As an objective bystander (after all, she is not going to write any of the code), she may often see issues which the people involved do not realize.


I have also seen ex-programmers turned Project Manager help come up with great (and simple) technical solutions; sometimes the people involved in the work do not see the forest from the trees - and a simple solution is best.


In my experience, I find that I can estimate the scope of a project before discussing it with the engineers. This way I can tell if the engineer is guesstimating in the correct ball-park, or if she is way-off. I can then discuss with them what they base their estimates on.


The Project Manager is more than the conductor on the bus, who does not need to know how to drive. She is also not simply the air-hostess who needs to ensure everybody is comfortable, but will never need to fly.


An efficient  Project Manager needs to be a co-pilot; somebody who is aware of the meaning of all the pieces involved.

Eating your own dog food

Obviously if you make dog food you don't want to eat it - but you do want to make sure that your dogs eat it.


If you don't have any dogs, then maybe you are in the wrong business.


Why dog food? That's an old expression, which you can read about here.


If you have no idea how your product works in the real world, then you have no idea how people use it, what problems they have with it and which features they don't understand.


To overcome this you can run a beta-test program. Or you can invite people off the street to come and use it. Often the interaction is video-taped for future analysis.


An important step is to use the product yourself; you, your employees and their families. 


As strange as it sounds, many companies think that they are eating their own dog food, but they are not.


Having the techies use the product is a good start, but not sufficient. After all, they know all the tricks - what the magical shortcuts are and the hidden features.


They also know what not to use, since it is delicate or broken.


Watching the secretaries, accountants and office managers use the product is more enlightening.


You may discover that the non-techies have a hard time using the product. 


At Answers.com we were surprised to discover that some of the accountants could not figure out the Alt-click; something the techies took for granted. 


Make sure that they have a contact person they can call to help them. This person will want to document what the issues are - and Product Management will want to analyze what needs to be improved.


The Project Manager would do everybody a favor to run this experiment periodically, and to talk to each and every non-techie to see if they actually are using the product. Often a period of "no complaints" simply means that the product is not being used.


This in-house experiment will also test the upgrade-process: How to ensure that your user base is using the latest version of your product.


If you cannot eat your own dog food, you need to ask yourself if you're making the correct product, because of you can't use it, then why should anybody else?


Bon appétit!


- Danny Schoemann

Too much of a good thing?

Since my current full-time job is to find a steady source of income, I have been spending a lot of time on LinkedIn.


It's a great tool for researching potential jobs, since apparently 70% of jobs come from connections. (Who needs protekzia when you have the right connections? J)


The concept is simple: Search for the company that is advertising an opening and discover who you know there - and then ask them to put in a good word for you.


What I noticed was that I had "1st level" contacts almost everywhere. That should be great, except that I would consistently discover that these were all people who had found me and linked up with me over the years - but I have no idea who they are.


Or else they were people who I had linked up with, as they worked at HR companies, or were famous people or vaguely connected to a company I worked at.


Bottom line: I do not know them. So?


So I cannot write them a note asking them to put in a a good word for me, as they have no idea who I am.


And because they don't know me, they never offer me a job. So what's it help to be connected to them?


Even worse: Since I am on "1st level" terms with these people and their company, I cannot easily see who we know in common; people who I may actually know and who could put in a good word for me.


So, I did the painful move of removing contacts! Painful because LinkedIn makes it rather difficult to remove about 100 contacts, painful because I had to double check that these are actually people I can safely remove, and painful because I hate throwing things away - no matter how useless they are.


I still have over 480 contacts - and that number still needs to shrink. So now, every time a contact "gets in the way", they get removed.


So if I refuse to link to you and point you to this post, you know why.


That said, on FaceBook, I have given up. I have almost 1,500 friends - and I probably know about 10% of them. But since these are people who want to read my Halocho-a-Day post, I have agreed to befriend them.


On FaceBook I only unfriend people who bug me with nonsensical posts are other forms of spam.


In Project Management one sees the same thing; sometimes involving too many people is counterproductive, and sometimes everybody needs to be informed. The trick is to be able to differentiate between the 2 cases.


- Danny

To be wise or to be right?

Yesterday I was watching a group of kids trying to define an ad-hoc game. They had about 15 minutes of play-time at their disposal.

Most of the kids just wanted to play and make up the minor details as the game went along.


There was one girl who was strong willed and was insisting and defining every possible rule - and she had a strong opinion as to what those rules should be.


Result: They spent the entire 15 minutes defining rules. Not all of them; some of them left earlier in disgust and went to play.


There's a delicate balance between a fully completed  spec and a perfect one.


This is one of those tough calls that a Project Manager has to make. The spec most cover everything. Or must it?


My father tells the story of how the programs in his time - coded on punch-cards (!!!) were able to handle leap years - including the exceptional ones - like the turn of the century. Their systems were Y2K-proof.


After all, they had no idea that the world would progress past punch cards - so the date formula was written for posterity.


At the time it was probably the best decision: the date formula is used all the time and adding an extra condition in the code was not a big deal.


After a spec is written, there is a spec-review meeting - where all those who will be involved in the implementation and testing should be invited; attendance is conditional on having first read the spec.


At those meetings there will be some heated debates about missing features or how to implement seemingly trivial functions.


The key is to listen carefully to what is not being said. Very often one of the vocal (loud or insistent) reviewers of a spec has a hidden agenda: e.g. a pet concept or implementation that they want to use - or learn how to use.


Or a skill set they want to use. Or a fear of the unknown. Sometimes it may be a (self declared) expert who (erroneously) thinks she needs to have original input to everything, otherwise she'll lose her job.


Sometimes it is a simple case of "Perfection is the enemy of Completion".


A trick that I learned for all meetings that get side-tracked or are taking too long: After 30 - 45 seconds simply interrupt the interruption and say "let's take that off-line".


Write it down and make sure to follow up (usually with an email, to as few people as possible) - otherwise they will stop letting you use that line. 


Often the follow-up email will be the end of the story. After all, the proposed concept was only to gain attention during the meeting and not to actually try improve the spec.


Sometimes the ideas being suggested are correct - but will kill the scope of the project. Be realistic about the life expectancy of the project. 


besides, it's often best to ship a feature-free product ASAP and then - if it's a success - to release frequent updates.


It's better to get requests for more features rather then complaints about poorly implemented features.




- Danny Schoemann

Setting priorities

In Agile development, milestones are typically 2 -3 weeks long and are called sprints.


Before each sprint, the team gets together and decide what needs to be done. Typically, the Product Manager will have a backlog of tasks from which to choose from.


Obviously, urgent tasks that will make a noticeable difference to income, traffic or user experience will get priority.


However, less-important tasks also need some attention, otherwise they will never be done.


The date at which a task was first presented to the sprint-prioritization meeting should be noted. If a task has been presented 3 or 4 times and is still in the queue, then a decision needs to be made:
Either do the task in the coming sprint, or delete the task.
If a task is simply being mentioned for old times sake, and everybody would like to do it but nobody has the time, and nobody can see the urgency, then it is simply taking up time in the prioritization meeting.


Since we live in a dynamic world, not every task can be planned 2 - 3 weeks in advance. That is why a typical Kanban board has more lanes:

1. Emergencies and Showstoppers. 
• Either the live system has become unstable (e.g. web site down,under attack or slow) or a 3rd party wants something urgently (e.g. a tracking code is being changed, a seasonal ad campaign was suddenly signed)
• This is not to be used for VIPs to push their pet projects; those have to be approved at the prioritization meeting.
  
2. Legacy bugs
1. For bugs that are found in code that has already been released. If these are added to a sprint, then eventually no new work can be done in sprints as all available time will be used for legacy bugs. Therefore, legacy bugs need to be taken care of in parallel to the sprints.
3. Maintenance
• Time needs to be allocated for maintenance of systems without becoming the man focus of the team, similar to the philosophy of legacy bugs.

These 3 types of incidences need to be attended to without affecting the sprint's schedule. With experience, a Project Manager will become adept at predicting the unpredictable and will know how much slack to add into the schedule.

Once a team has agreed to its upcoming sprint, an atmosphere should be created  to ensure that the team can focus on its sprint, and realizes that it is expected to meet its commitments, come what may.

This is easier to enforce if the major players involved are in attendance at the prioritization meeting, and they they each have a say in defining the sprint.

If management are in the habit of interrupting sprints with special demands, then they should also be present at the meeting, so that they can later be confronted with "But you agreed to the scope at the meeting. Please keep this for the next sprint."

Stop starting. Start finishing.

When we started using the Agile development concepts at Answers.com, we started by putting up a Kanban board.


We then created a post-it note for each active project.


Result? The board was not big enough and the concept of Kanban looked overwhelming. How were we supposed to track this many projects?


That's when we took the drastic step of stopping many of the projects we we re working on. We implemented the "Stop starting; Start finishing" philosophy.


Initially it was counter intuitive: We were trying to get more done by doing less?


Yes. That was the game plan - and it worked!


Instead of thrashing between multiple projects, each team was focused on a single project or milestone. More than that: we stopped using each team to its full capacity!


What? You had people do nothing?


No. Never. Worst case scenario, the spare people would take care of things link technical debt; those little annoying things that really should be done but nobody gets around to them.


Most of the time these spare people were taking care of emergencies and other rush jobs that had to be done immediately, if the company was to survive. They could also step in to replace a team member who is absent, or do pair-programming on difficult issues.


What happened? Since the teams were now focused on a single task, and didn't have to spend time deciding which project was more important, and since they were not distracted by "emergencies", they started delivering in record time.


They were now often able to deliver in 2-week increments, including testing. Previously they were delivering in 2-month increments with many weeks of testing and integration issues before the project could actually be delivered.


So the fewer things that were started, the faster they get finished. Throughout goes up, as well as team morale.


It takes while for management to get used to the idea that a pet project is waiting for a slot. But they eventually understand that once that slot is found, their project will be finished in record timing.


But don't they classify their projects as emergencies? In a future post we'll discuss what are emergencies and what gets to jump the queue.


Lesson learned: Do one thing at a time, and do it well. 


- Danny Schoemann

RetroSpec: The quick long way

RetroSpec: The act of writing the spec after the code has been written.

For various reasons, sometimes it makes sense to first write the code and only afterwards to write the spec. 

For example: You may not be sure what is technically possible, you hope for at least some minimal functionality, but discover that it's trivial to implement a fully-blown feature.

Sometimes it doesn't make sense, but it simply happens; a quick fix or tweak turns into a feature. This could be the result of a programmer having a sleepless night and dedicating it to the cause, or a team having an internal competition.

Or it may simply be a case of feature-creep.

If it's already coded, why the spec?

If nothing else, QA needs to be know what to test, and without a spec that cannot know what is broken or purposely missing.

If you keep documentation up-to-date, then you will need a spec so that the technical writers have a starting point.

But the most important reason to RetroSpec is to enable a spec review. Experienced Project Managers are adept at discovering the corner-cases, but can only do so if there is a spec to review.

If need be, the Project Manager should write a spec, simply in order to ensure that the corner cases are covered.

In a future post we will give examples of typical corner cases, and how to find them.

- Danny Schoemann

Scrum: Rugby or Project Management?

A scrum in rugby is a is a way of restarting the game and pits the 2 teams against each other in close proximity. It's one of the less gentlemanly parts of the game.

In Agile software development, a scrum is a daily meeting to sycn up all teams - similar to what I described in a previous post titled: Sync up in 15 minutes: The daily stand-up

The agenda of the daily scrum is always:

• What has the team done since yesterday?
• What is the team planning to do today?
• Does the team have any problems that would prevent it from accomplishing its goal? 

The scrum is run by the Scrum Master - who is often also the Project Manager - and, as expected, it is the role of the Scrum Master to be in charge of finding solutions to any impediments that arise.

The reason I keep away from the term scrum is because of its rugby definitions.

• The daily meetings do not restart anything; most healthy projects do not time-out every 24 hours.
• The daily meetings don't pit the teams against each other. 
• I prefer to think of projects as being made up of people who work together to a common goal,  as opposed to the various members of a project seeing themselves as being on opposing teams.
• The word scrum has violent undertones, which are wholly inappropriate to software projects.
• The British also use scrum as A disordered or confused situation involving a number of people - which should not be the case in a well run project, except - maybe - when the concept of scrum is being introduced for the first time.
  

Therefore I prefer that my 15-minute daily stand-ups not be called scrums.

- Danny Schoemann 

Overtime and All Nighters

Mid-1990s: The Gold Master Disk had to be in Ireland by the following afternoon, if we were to ship on time.


This required us to work all night; I got home in time to see the sunrise, and was expected back at work after lunch.


I was there because each new build required a new setup - and I was Mr. Setups - in those pre-internet days when CDs were a novelty and all programs were installed.

We made it! The Gold Master Disk was shipped, thousands of copies were made, put in boxes with a huge manual, and shipped back to us.

By the time they had arrived, we had discovered some serious bugs and the entire shipment was declared unfit for use. When the company closed down a few years later, we finally threw the entire batch into the dumpster.

That was my first introduction to all-nighters, and the more I lived through them and watched the results of all-nighters and overtime in general, the more I am against them.


After 10 - 12 hours of work, most - if not all - people start being too tired to think straight.


If you cannot think straight then you are a menace on the road and a useless engineer, tester or writer. You - and the project - are better off if you would go get some sleep and restart early in the morning with a clear head.


There will occasionally be that rare emergency that really warrants serious overtime.


When Answers.com - then still gurunet.com - was almost ready to launch, Walt Mossberg informed them - on very short notice - that he was going to write about it them the Wall Street Journal on a specific day. The team did an all nighter to be ready for their premature launch.


But as a general rule, chances are that you are wasting time working too hard. Some advance planning and professional Project Management would be a better idea.


Work smarter, not harder and longer.

- Danny Schoemann

Any decision is better than no decision

Since the Project Manager is involved in keeping all the pieces of the project together, he is the natural address for questions.

One of the items that need to be addressed during the early stages of any project, is: "who is responsible for making decisions?"

However, many of the questions that arise do not have a correct/incorrect answer, the simply need a decision.

Examples would include:

• What font size/color to use
• What exact wording to use (OK or Yes or Go)
• What happens in corner cases which nobody though of and probably never happen

Most of the time the answer is not really important. What is important is providing an answer.

The sooner the answer is provided, the sooner the developer can get back to work.

A Project Manager needs to be courageous and simply make a decision. This decision then needs to be documented (so that QA know about it, for example) and then communicated to whoever was supposed to make the decision.

The only data the Project Manager needs is how long would it take to reverse the decision.

 As is usually the case, these changes are trivial and - if the engineer is aware that the decision is not 100% final - then he will implement it such that it's trivial to find and change.

In the rare cases that the decision was wrong (or: somebody thinks another answer is better) then a change can be made. If this change request comes soon after the decision is made, then it will be quick and easy to change.

But beware: nothing is more permanent than something temporary.

My first assignment as a Project Manager was WordPoint 1.0 - and it needed 3 icons:

1. Dictionary
2. Encyclopedia
3. Dictionary & Encyclopedia

Initially the developers used a blue book for Dictionary and red book for the Thesaurus; standard icons that came with the development environment.

Using MSPaint we created a blue book sitting on top of a red book for the 3rd icon.

After a long process of getting a professional looking set of icons, the product shipped with the demo icons. No other alternative made it through the decision process.

How this happened was a lesson in how not to make decisions - something warranting it's own post.
So make sure that your initial decisions are acceptable to be shipped, because they probably will be.

This may also explain strange error messages - like How did you get here? -  that you sometimes see in products. They were planning on getting some fancy wording - and it never happened.

- Danny Schoemann

Emotions and Projects

Conundrum: Should a Project Manager be emotionally involved with her project?

A  Project Manager needs to consider her project as the most important thing happening in the world. It needs her entire focus and concentration.


The more she thinks about it in the shower and while falling asleep, the better chance of her coming up with ways to improve the project and to realize what is missing and to identify potential trouble before it becomes obvious. 

This is why it's best when a Project Manager has only a single project to manage, at any one time.

That said, the worst thing that can happen to a project is to have the Project Manager emotionally involved with the project.

Why? Because it's crucial that the Project Manager be able to make decisions based on data and not on emotions.

Once a Project Manager is emotionally involved in a project, she will not be able to make drastic changes; she will fight any attempt to change, shrink or otherwise modify the project, since she is now emotionally attached to this project; the way it is now.


Once emotions are involved, then logical arguments become futile. Worse - this may hinder the project form completing, since that would be like saying good bye (or killing) a good friend.


So while the project needs to be the Project Manager's main focus in life, it must remain a project; something that needs to be defined - and continuously redefined, tracked, updated and completed.


Decisions need to be made based on data and facts. In a future post we will discuss how to make decisions when no data is available.


When asked her opinion on any aspect of the project, the answer needs to be "I don't have an opinion; whatever is best for the project is my opinion". If needed/warranted, the answer can include "I have an opinion, but my opinion is not relevant."


This does not mean that the Project Manager should not give input before the decision is made.


This does not mean that the Project Manager cannot suggest a better and/or different solution if it would seem to improve the project.


It does mean that the Project Manager will not try change a project merely to prove herself right. A Project Manager with an big ego is a Project Manager who cannot be trusted to make decisions in the best interest of the project.

The Magic of Milestones

Project Managers talk a lot about milestones.

What are milestones and what do they do?

Milestones as per the dictionary are:

1. A stone marker set up on a roadside to indicate the distance in miles from a given point.
2. An important event, as in a person's career, the history of a nation, or the advancement of knowledge in a field; a turning point.

Or - closer to our discussion - Milestone or  key activity:

1. (industrial engineering) An activity that possesses major significance. Also known as milestone activity.

It makes sense to break up a project into milestones, each milestone being 2 - 3 weeks long. At each milestone the team will deliver something.

 

This allows the project to have points along the way (milestones) at which to be able to pause and check:

• What have we done so far?
• Is it what we want?
• How long did it take vs. how long we thought it would?
• What's left to do?
• How long will it probably take us?
• How does that compare to our original estimate?

It's a also a good time to take some measurements:

• Is the product still/already fast enough? Small enough? Cheap enough? or any other metric we care about.
• Try getting feedback from internal users, or the QA group or a small test/beta group.

Milestones also give a sense of achievement. We have finally delivered something. Not being able to come up for air for many weeks / months / years can be depressing, or wear down the team.

A milestone is a good time to have a mini celebration, pat each other on the back, do some team building and rejuvenate the team for the next milestone.

Millstones break down the project into smaller pieces making it easier to report progress.