Tuesday, November 17, 2020

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:

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes


Of course, the devil is in the details; I plan on studying how they see each of these 12 steps - and commenting on them. Stay tuned.

Wednesday, November 14, 2018

Project management has changed!

 "Project management has changed" is what I was informed.

As a result, this head-hunter refused to consider me for a PjM job; since I've been doing 1,000 other things for the past 7 years.

The fact that I've been sharpening my technical skills and updating my knowledge of the Software Development world is irrelevant.

So, my questions are:
  • Has PjM changed, and how?
    • I don't recall noticing any new fads, even though I frequent sites like pm.stackexchange.com almost daily, and I am ranked in the top 12% of 23,000+ users.
  • Does it really matter that I haven't done any active PjM work for a while?
    • Keep in mind that I never formally learned PjM, it's a skill I'm born with.
  • Shouldn't it be advantageous that I have hands-on experience with state-of-the-art technology?
    • Or do they prefer PjMs who haven't had a chance to keep up with the latest technologies?

Your thoughts are appreciated. My thoughts on the subject were written 6 years ago at the post titled
Why a technical Project Manager?




    profile for Danny Schoemann at Project Management Stack Exchange, Q&A for project managers



    profile for Danny Schoemann on Stack Exchange, a network of free, community-driven Q&A sites

    Wednesday, November 16, 2016

    Do projects ever end early?

    For a while I was an active participant in the StackExchange Project Management beta site.

    One of the 6 questions I asked was Do projects ever end early?

    The fascinating part of this was that it has been viewed about 6,400 times and generated 14 answers! 
    (That's a lot of traffic for a site that has been in beta for almost 6 years because it averages a mere 1.5 questions per day. It needs 10 new questions per day to get out of beta.)

    It seems that a lot of people are wondering the same thing: Do projects ever end early?

    The question I posed was:
    When scheduling, I tend to add a lot of reality into the guesstimates I am provided with.
    I always add in generous amounts of probable sick days for manpower and extra time for integration and bug fixing. (All this based on decades of experience.)
    As a result, my projects tend to deliver on schedule. But they never finish earlier than expected.
    Now I'm wondering if the projects would deliver earlier if I didn't pad the schedule as much.
    Would everything move a little faster if the teams had the incentive to meet deadlines based on the data they provided, as opposed to the padded ones I provide?
    Or put another way: Does work expand to fill up available time?

    To see the diverse answers, you'll have to go to the site - way too much to paste here.

    But the bottom line remains that with a realistic schedule you could finish on time and possibly early.

    A realistic schedule is not based on when the customer (or boss, or calendar, etc.) wants it done.

    A realistic schedule is created by finalising the spec and then having an experienced Technical Project Manager create a schedule based on input from those doing the work. This schedule will include time for integration, testing and sick leave, amongst other things.

    Note that I wrote based on input from those doing the work. An experienced and Technical Project Manager will have a pretty good feel how to take those guesstimates and morph them into a schedule.

    E.g.: An experienced and Technical Project Manager will know that people do not realistically work 9 full hours a day, and that no task can take less than a few hours. More about that another time.








    Monday, January 16, 2012

    Managing without management

    For the past 6 weeks I have been working at a new company - hence the lack of updates on this blog.

    My previous employer - Answers.com - was big into management and SEO.

    My current employer - Hyperlync - does not believe in either.

    Their site is all but non-existant - and most pages are carefully spider-proofed. They generate revenue by creating products that people actually use, and they have no need to be in Google's index. Those people who need their products know where to find them.

    This means that we never hear - and really don't care - about Google events and other tragedies that affect SEO-driven companies. What a relief.

    They also don't believe in management. The 3 founders all work for a living; 2 of them write code the 3rd does the sales & marketing.

    There are no status reports and nobody looking over your shoulder. As soon as a product is sold, the relevant employees are informed and each does his part to make it ship.

    Since there are no teams, you cannot rely (or hide behind) your teammates or superior to get the job done.

    While this may sound like a startup, it's not - and they are already profitable; so much so that we each got the latest version Kindle to celebrate Chanuka / 2012.

    There is one Project Manager, but she mainly does product-management; deciding on the look-&-feel. She does almost no coordinating, scheduling or running around.

    More on management-less companies in future posts.

    - Danny

    P.S. So what do I do? I went back to 1995; doing setups. This time on Linux, Mac, Windows and Androids.

    Sunday, November 27, 2011

    Bottlenecks: Never assume the experts know better

    As the saying goes: "Experts built the TitanicAmateurs built the Ark."


    It seems to be human nature to rely on experts and not question their decisions. After all, if they are so clever, who are we to question them?


    But sometimes it seems that they are self declared experts and/or it is us who declare them as experts and then believe our own prophecies.


    Jerusalem has 2 new fast transport systems: A light rail and express buses. The aim is to eventually replace the latter with another line or 2 of trams.


    I always wondered what was the advantage of transport-by-rail - especially intra-city where speed is not an issue.


    Light rails are great when they work; the idea is that cars and pedestrians have to keep out of their way, as the trams are inflexible. They are quiet and don't need to tank up as they are electric.


    Two weeks ago I saw that anything travelling on rails suffers from the typical bottleneck problem, as to be expected.


    First I saw a train that had started pulling out the station and got stuck; I have no idea what precisely happened. For about 20 minutes it simply stood there. It was jam-packed and nobody was allowed off. Eventually the driver came around to the cabin at the back of the rain and drove it back to the station and let everybody off.


    So what happens to the other trains? They have no way around the stuck train, so essentially all transport  heading North was stopped. It was a matter of time until all South bound traffic followed, obviously. (There are a few places where the North and South bound rails have an option to cross over; but running the trains in both directions on the same rail doesn't sound like a great idea.)


    Later that day was one of the biggest funerals that Jerusalem has seen. It was close to the rail line. It brought the train system to its knees - for the second time in the same day. Since everybody wanted to get on the train, the train got stuck at every station, as the doors don't close if people are in the way. I sat watching the electronic devices inform us the the next train was in 10 minutes, then 15 minutes and then.... it announced "train stopped". It took 45 minutes for the train to arrive.


    Despite them announcing that the next train was right behind (and probably 3 more behind that one) everybody tried to get on this one!


    Buses are way more efficient! I often seen 3 buses play leap frog; one fills up at a bus stop while its twins head for the next stops.


    Even in the express bus lanes, a bus will overtake another, if the first bus is stuck or taking too long to move.


    There is a way to get both the advantages of quiet electric transport and not have to deal with rails.


    In Johannesburg they used to have (and probably still do, but I have not been there in over 20 years) double decker electric buses with 2 antennas connected to the overhead electric lines. If a bus got stuck it could be unhitched from the wires and other buses could get by. 


    They also had to do load balancing; if too many buses were behind each other trying to get up some of the steeper hills, then they all would get stuck unless some of them stopped, giving the power back to the ones in front.


    Maybe the light rail was not such a brilliant idea after all...



    Thursday, November 3, 2011

    Are all changes really improvements?

    I can just imagine it: The yearly review at Egged; the Jerusalem bus cooperative. The major request for change must have been to get rid of the need to punch those paper bus tickets.


    It was slow, it meant interacting with each passenger. it meant that the person driving a million-dollar bus spent a good part of his day punching holes into paper; paper handled by other people and he had no way to wash his hands.


    So, many years ago they created the monthly bus pass. Now the bulk of travelers simply flash their passes and walk by. What a major improvement.


    In parallel they decided to upgrade to the 21st century and computerize the system.


    Welcome to CityPass. Each passenger has a debit card - this should really improve things.


    But, as often happens, this was not thought through carefully. Now every single passenger needs to insert their bus card into the machine; the driver punches a button and - after the light on the machine turns from red to green - you can remove your card and the line behind you can advance slightly.


    As an added bonus, at major bus stops (like the Central Bus Station) you can no longer enter by the back door after an inspector punches your card.


    Net result: Travel time by bus has increased noticeably.


    A spec-review would have been in order here! A project manager would have picked up on issues like:


    - The machine which validates the cards better be lightning fast if the driver is to deal with each passenger


    - Alternatively there could be card readers at every door so that the driver does not have to deal with any passengers. This is how the light rail has it planned out. On 1 Dec we shall find out if their system really works.


    A few simulations would have picked up these issues.


    Now I'm waiting to see what happens as the magnetic strip on the cards start be wear out... that will surely wreak havoc on the system as people alight and discover their bus cards are dead...


    Conclusion: Not every change is an improvement.

    Sunday, October 30, 2011

    Spec review: Airbags?

    One of the many skills a Project Manager needs, is the ability to review functional specifications.


    A Project Manager needs to be able to run a spec-review meeting and follow up the action items and document the changes resulting from the meeting.


    Another required skill is the ability to persuade people that everything needs a spec and a review.


    Why is that? Let's take a non-programming example, for a change; since I've been getting complaints that my blog is very programming oriented.


    In 1971 GM added airbags to the driver's side. Since the airbag worked well for the driver, why not install it on the passenger's side also. Source: Wikipedia: Airbags.


    Sounds simple enough: Here's what the MRD (Marketing Requirement Document) may have said: "Take existing design of airbag and add it to the passenger side."


    Hardly needs a design, functional spec and review, does it? Seems that implementing it will be trivial; what could possibly go wrong?


    If anything, it's way more complicated to add it to the driver's side, since the steering wheel is in the way.


    Fortunately they did a spec review, and here's some of the issues that were revealed:


    • What happens of an infant is in the passenger seat? Won't the airbag serous injure / kill it?
      • Solution: Put a weight sensor. Do not deploy if weight less that 3 year old child. 
      • Action item: Find out minimum weight from medical dept.
      • Action item: Inform legal that a new "anti-infant" clause needs to be added to standard car contract.
    • What happens if the infant is in a car seat? it will be heavy enough to be detected as an adult... yet the result could be fatal...
      • Add switch to manually override the airbag.
        • Where should we place this switch? passenger side? drivers' side? in between?
          • Since it's to protect infants, needs to be on driver's side.
          • Needs to be far enough away from passenger that kids don't play with it during travel.
        • Does it reset when ignition is turned off, or does it remember its state?
          • Could be fatal if it resets; better if it remembers state.
        • Add a warning beep to sound when airbag is turned off.
        • Add a warning beep if passenger is too light and airbag is turned on.
        • How can we prevent it being turned off accidentally?
          • Maybe it should require car-key to flip on/off.
          • Decisions: try both options and track customer feedback.
      • Add light to dashboard to indicate that airbag on passenger side is deactivated.
      • Action item: Design relevant icon - graphics dept.
    • How will drivers know when to turn the airbag off, and what all the icons and beeping mean?
      • Action item: Get stickers made to explain the infant-hazard; get wording from legal, design from graphics dept.
    • Should airbag always deploy?
      • Maybe it should only deploy if the seat-belt is buckled? This way it won't unnecessarily if only groceries are in the passenger seat.
      • On the other hand, the airbag is most useful when the passenger is not wearing their seat-belt.
        • Decision: Deploy independently of seat-belt being buckled.
    As we can see, this trivial, easy to implement feature has become a project involving the following departments: legal, graphics and medical.

    It requires a redesign of the buttons sections and the icon on the dashboard. It also requires a new type of switch that gets turned by the key.

    We now know why the first passenger-side airbags didn't appear until 1973.

    Finally, we also have plenty information in order to create a full-length functional specification, which everybody will understand why it's needed, and many people from various departments will be required to review.  

    So now we know!

    - Danny Schoemann

    Monday, September 19, 2011

    The End Game: Jerusalem Light Rail

    The Jerusalem Light Rail is once again in the news: The drivers all had temporary licenses - all of them expired 3 days ago. Only 12 of them have been renewed. Somebody forgot to take care of renewing all of them...


    So now we have the train running once every 30 minutes; even at once every 4 minutes it was crowded...


    The Jerusalem Light Rail project is a fascinating one to study; it was running way behind schedule and budget until the current mayor Nir Barkat took charge.


    His first question :Where's the schedule and the Project Manager? Yes, he comes from the world of software. :-)


    The answer? Well, hum, there were a lot of people in charge; one for the infrastructure, one for the electricity, one for the actually trains, one for the software, one for the traffic lights and the list goes on. But there was nobody in charge of everything.


    Result: Everybody could blame everybody else for delaying the project. (The initial launch date was January 2009!)


    Nir changed that, and the project started moving. When the August 19, 2011 deadline loomed large, those involved started their old story about not being ready. Nir wanted to know what wasn't ready.


    The billing system? Too bad. The train will have to be gratis until you get that one right.  Apparently the system crashed when it was tested in real time; lots of people buying tickets all over the city at the same time. Would make an interesting study in design and testing.


    The obvious advantage is that the trains are free, meanwhile. The disadvantage is that they are full to capacity, as every loafer in town - and all bored kids - spend their time on the air conditioned trains.


    The traffic lights are not synchronized yet with the train? Too bad. They will have to stop at the red ones. (It's really pathetic; at the main bus station there's a traffic light for pedestrians to cross the rails. It's not synchronized (or needn't be) with any other traffic light. Yet the train often has to stop, since it's green for the pedestrians - all of 10 feet from the train station!) 


    Supposedly they are working on this project; hopefully not the same people in charge of the licenses.


    How they plan on synchronizing the traffic lights for the train without grid-locking vehicular traffic is  not clear to me. I'd like to believe that there are experts on this subject who know better than me.


    The trains sometimes run off the rails? This was discovered in high-speed testing. Solution: Drive slowly until we figure this out. Makes one wonder why the rails are needed...


    The advantage is this even if you can see the trains approaching, you will often manage to get to station before the train, since it also drives slowly and also gets stuck at all the traffic lights.


    Lessons for Project Managers:

    • Without a single Project Manager in charge of everything there's going to be chaos. Each major element can have its own Project Manager, but they all have to report to a single person.
    • Ship as soon as something is ready; early users are as good as beta testers.
    • Ship often, with minor improvements.
    • Not every "bug" or "issue" is a showstopper and a reason not to ship.
    • Think of creative solutions. Sometimes the experts know too much, and need to be overridden. 

    There's probably more obvious lessons; feel free to add them in the comments.


    In a future post we'll discuss how Egged rolled out the CityPass; enabling single payment for both trains and buses.

    - Danny Schoemann

    Labels: , , , ,

    Tuesday, September 13, 2011

    Broken Telephone

    A Project Manager spends a lot of time finding out what people are doing and what is preventing them from progressing.


    Removing impediments is one of the undocumented roles of a Project Manager; maybe it's time to change that.


    Impediments come in a variety of flavors:


    Sometimes it's a missing piece from a 3rd party. If the Project Manager can follow up with the 3rd party, then the engineer can  continue doing what she does best, while the Project Manager "wastes his time" chasing the culprit.


    Sometimes a lot of non-engineering work needs to be done, like entering a lot of data or editing a lot of existing data. Once again, if the Project Manager can take care of it, the engineer can go back to doing real work. The Project Manager can either do the work or outsource it to somebody who is available; a visiting child or a bored QA member waiting for the project to progress.


    Sometimes the Project Manager will discover that the engineer is waiting for a component or information from another engineer. It's best practice to go to that other engineer and double check that they realize that somebody is waiting for them to deliver something.
    Find out if it's on the top of their list of things to do; you do not want an engineer waiting for something that  may take a long time to arrive, since it's not on the list of things to be done in the immediate future.
    If there's a conflict of scheduling (one fellow needs it now, the other fellow has no intention delivering it this week) then it needs to be escalated.
    It can be brought up the the daily update meeting, if they happen. More efficient is to simply approach the head of engineering and ask her to intervene and solve the conflict. She may decide a meeting should be called, or she may decide to change priorities on the spot.


    Sometimes a Project Manager will discover that one person is expecting something to be delivered and the other party claims they already delivered it.
    One solution  is to go back and discover where it was delivered to and how come it never arrived.


    Better yet, is to get the 2 engineers to talk to each other - else you may spend considerable time playing broken telephone. Besides, it's important to teach the engineers that they can talk to each other. :-)
    The best tactic is to ask the one engineer to accompany you - the Project Manager - to the other engineer, and to have a impromptu meeting.
    Listen carefully to how they solve this; it may give you valuable insight into the personalities and work habits of the engineers. This is information that will help you preempt future similar issues.
    And make sure to follow up to ensure that the solution actually worked. There's often a gap between the theory and the facts on the ground.


    As a rule, you do not want to be spending time as a go-between - the broken telephone - between people. A quick stand up often solves the problems.


    - Danny Schoemann








    Thursday, September 8, 2011

    PMO: Not the prime Minister's office

    So, if PMO is not the Prime Minister's Office, what is it?


    From Answers.com
    The Project Management Office (PMO) in a business or professional enterprise is the department or group that defines and maintains the standards of process, generally related to project management, within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution. In some organisations this is known as the Program Management Office (sometimes abbreviated to PgMO to differentiate); the subtle difference is that program management relates to governing the management of several related projects.
    PMOs may take other functions beyond standards and methodology, and participate in Strategic Project Management either as faciliator or actively as owner of the Portfolio Management process. Tasks may include Monitoring and Reporting on active projects (following up project until completion), and reporting progress to top management for strategic decisions on what projects to continue or cancel.


    So, what do we have here? Looks like somebody tried to split the classic Project Manager's job into various smaller jobs. To me, the obvious result will be more overhead - as more people are involved - and less efficiency, as a Project Manager needs to have full control over his project.


    I've been part of attempts to have more than a single PjM on a project. It simply does not work; the Project Managers have to spend huge amounts of time coordinating between themselves, or else they step on each others toes and either do duplicate work or send out mixed messages.


    If a single Project Manager cannot manage the project, then it needs to be split into almost unrelated mini-projects. Then it seems to make sense to have a PMO, but, on second thought, to be efficient, there would be too many meetings and updates and not enough hands-on Project Manager. Having each Project Manager attend the status-update meetings of the other projects and receive its updates would be more efficient.


    So let's analyse what the PMO does:


    [The PMO is] the department or group that defines and maintains the standards of process, generally related to project management, within the organization.


    I smell trouble. A group of people who want to regulate Project Management. :-)


    The PMO strives to standardize and introduce economies of repetition in the execution of projects. 


    At some level, Project Management is all about repetition. Get daily updates, have daily meetings, check the bug-count status daily, update the schedule and send out a daily update.


    I'm not sure I understand what they are trying to save, unless they are worried that similar projects will be initiated. But who would initiate these projects? Surely all Project Managers keep up to date with what's going on around them; at least on a high-level.


    If we're talking about duplicate code or similar testing - that would be the job of the head of engineering/QA to take care of.


    The PMO is the source of documentation, guidance and metrics on the practice of project management and execution.


    This will ensure that the Project Manager has no connection to the rules, and therefore will ignore them and/or make up new ones. The most efficient rules are put in place by people who learned the hard way. Besides, with the fast evolution of technology, any rules that are 3 years old will be archaic. New rules need to be put in place all the time by the people involved, not those disconnected from the field.


    PMOs may take other functions beyond standards and methodology, and participate in Strategic Project Management either as faciliator or actively as owner of the Portfolio Management process.


    Again, my experience is that a Project Manager is most efficient when he's in full control. If this facilitator is not on the same wave length (and starts arguing with the PjM at meetings) then the PjM will lose control of the project. Advise to PjM's needs to be given privately, not as a facilitator at meetings.


    Tasks may include Monitoring and Reporting on active projects (following up project until completion), and reporting progress to top management for strategic decisions on what projects to continue or cancel.


    That's what a Project Manager does. 


    Maybe a PMO works well in huge organisations where there is a total disconnect between the projects and management. I would love to work in or with a PMO for a while in order to understand what it does.




    - Danny Schoemann