… until we meet again!
… until we meet again!
In November, 2014 I began an annual tradition: I collected a list of commonly observed national and religious holidays for the coming calendar year, and suggested that those holidays observed by the project team be accounted for as non-working days in project schedules for the coming year. But it’s time to remove myself from the equation: I’ve prepared an Excel workbook that will calculate my (now expanded) list of national and religious holidays, from 2021 through 2030.
Many holidays are observed on a specific date, such as Canada Day. Organizations that observe these holidays usually have their own rules for what day to take off when they occur on a weekend, so excepting US Independence Day and Christmas, I don’t try to predict whether Friday or Monday will be non-working. Other holidays are based on relative dates such as third Monday of January, like Martin Luther King’s Birthday. In a couple of cases, the authorities added a wrinkle, such as last Monday in August. Others are based on a Lunar calendar; rather than try to calculate Lunar New Year or Passover, I created a look-up table and populated it through 2030.
Download the workbook using the link at the bottom of this page. Then enter the year you want to schedule for in the cell at the top of the Holidays tab, highlighted in orange.
Navigation depends on which version of project you are using. In Microsoft Project 2007, under the Tools menu, select Change Working Time. In Project 2010 and later, on the Project tab, select Change Working Time. You can then enter the holidays under the Exceptions tab. Note that Exception days appear in the calendar in blue; however, if you have selected one of the exception dates, as shown in the example below, the date will appear in red. Scheduled non-working days appear in gray. Note that you can also make an exception of a scheduled non-working day, so that it appears to be a working day. Use this feature carefully – having some of the team working over a weekend can easily throw off the scheduled for the entire team.
You can also create custom calendars, if your team is spread across multiple countries with different holidays. Again, the version of Microsoft Project you are using makes a difference in navigation. In Project 2007, under the Tools menu, select Change Working Time. In Project 2010 or later, on the Project tab, select Change Working Time. Click the Create New Calendar button in the upper right. Give the new calendar a meaningful name, then click the Make a copy of radio button. Select the Standard calendar from the pull-down list. Then click OK.
At this point, you can add the dates you want to mark as exceptions to the working calendar. Enter the Name, Start, and Finish dates. Then click the Details button. Click the Working Times radio button. The default working hours will appear; change them only if necessary.
Click OK to return to your custom calendar and enter the non-working dates that apply. Then assign each team member to the appropriate calendar using the Resource Sheet, in the column labeled Base.
While it can be helpful to have MS Project automagically re-schedule after you make a change, be cognizant of what can happen when you have a summary task involving team members using different calendars. A change of one day in one detail task can cause the summary task completion date to change by two or more days. Scrutinize the results before you publish them, and investigate anything that seems wrong.
Once your career has progressed beyond managing a few folks co-located in one cube farm, your ability to think globally and manage a geographically distributed team will be key to how far you can go. Develop your multi-cultural knowledge, awareness, and communication skills, and when someone is needed to manage a project that crosses borders, you’ll be ready.
I’ve grown weary of internet debates about software development methodology, argued by people who don’t really understand the vocabulary they use. Allow me to provide a brief lesson on three of the most commonly misused terms.
A little history: Winston Royce is attributed with defining the methodology now called “waterfall” in his 1970 paper, Managing the Development of Large Software Systems although that term never appears in the paper. Royce was offering his opinion on what worked and what didn’t work after nine years of software project experience. While software for internal use could get by with just analysis and coding, paying customers needed a more rigorous approach. However, Royce argued against using a purely sequential process for developing software. In his paper, he critiqued several diagrams, beginning with the one below.
Royce noted that the lack of feedback between the sequential activities was a fatal flaw, but that the feedback flows had to be managed in order to avoid runaway scope. He explored several other diagrams in his paper, which became progressively more complicated until they resembled a spaghetti-and-meatballs dinner for sixty or so. Plainly, feedback was necessary but it was possible to become paralyzed.
The earliest use of waterfall in referring to a software development model may have been in a 1976 paper on software requirements by Bell and Thayer, which referred to Royce’s paper. During the 1980’s, there were several “structured” software project management methodologies marketed by various consulting firms that looked much like the more complex diagrams in Royce’s paper, but no one has actually used any of those methodologies for decades. None of them called their methodologies waterfall, either.
Technology has changed dramatically in the last half-century. Where the primary cost constraint in 1970 was computing time, it is now knowledge-worker time. Where the primary technical challenges were data storage and code efficiency (does anyone remember dates with two-digit years?), storage and retrieval technology now provides terabytes for the price of a good dinner, free relational databases, structured and ad hoc queries that return results in milliseconds, and a global network with connections to tens of billions of processors. As a result, the nature of software products has changed from calculations of orbital mechanics and industrial controls, written by and for large corporations and government agencies to (overly) personal communications and videos of cats, paid for with marketing messages.
In Royce’s era, programmers and users submitted Hollerith cards and (maybe) a day later scanned the results on 132-column green-bar paper. Today, users have the expectation of point, click, fill-it-in-for-me, and tell-me-what-to-correct. Where once coders spent most of their time writing code to detect and handle logic breaks and invalid inputs, they now focus on the presentation layer. No one optimizes for memory usage, and execution speed only becomes a concern when responses are returned in more than two seconds. There are standards for virtually everything, reducing the effects of obsolescence, and a global communication network that facilitates collaboration across and between continents and cultures.
Software development today bears as little resemblance to 1970 as modern agriculture does to Mesolithic-era farming in the Fertile Crescent twelve millennia ago. But there are still farmers and there are still programmers, and the micro-economics of production still apply. And the same seven activities identified in Royce’s diagram are still needed, even if we organize and execute them differently.
Most modern software development organizations will tell you that they use agile methods. The term refers to the Agile Manifesto, composed by seventeen thought leaders at a conference on lightweight software development methods in 2001. While there are several software development methodologies marketed as “agile,” in most organizations “agile” is a synonym for Scrum. Other common “agile” methods include Kanban, XP, and DSDM. Each of them addresses the seven basic activities, although the level of detail varies widely.
Note that “agile” in this context is a label, rather than a performance characteristic. While many organizations use these methods (or combinations of them) effectively to produce reliable, maintainable software that creates real value, many others flounder. An entire industry of consultants and trainers offer their services to those who want to succeed with agile methods. Many of these experts (and their students) disparage what they assert are “non-agile” approaches with the generic epithet “waterfall.” That doesn’t make them so.
As noted, the Agile Manifesto arose from a conference on lightweight methods. While that certainly describes much of modern software development, many software projects require compliance with a variety of contractual, legal, and regulatory requirements, in addition to functional and technical requirements. These complex projects tend to include a lot of requirements elicitation, analysis, and design tasks that must be finalized by people who are not coders before decision makers will give their approval to proceed with actual coding. Because of these controls and process requirements, numerous parallel workflows by people who are not coders, critical decisions that often have nothing to do with code or coders, and the higher cost and longer duration of complex projects, they are typically managed using predictive methods—in other words, estimating task duration in advance, in order to schedule activities so that knowledge workers who are not coders can manage their workflows.
Complex projects include most government-funded projects, most projects for heavily-regulated businesses, and nearly all products in the medical devices or aerospace industries. Agile methods are used for some project activities, in parallel or in series with other activities using other approaches, when it makes sense to do so. People who don’t understand (and don’t care to understand) anything about these external controls and processes often dismiss them as command and control or waterfall or some other epithet. The rest of us understand that you have to skin a rabbit before putting it over the fire—see “Payne, Podrick” for an illustrative misuse case.
A project should be approved based on a specific business case, with parameters such as a scope, delivery schedule, budget, a staffing model, and performance and quality goals that are realistic. Ed Yourdon defined a death march project as, “One whose ‘project parameters’ exceed the norm by at least 50 percent.”
The business case should be updated whenever the business environment changes or assumptions prove to be invalid. An oversight committee should meet periodically to assess progress and risks, along with the probability of achieving the goals in the business case. This committee should be empowered to adjust any of the aforementioned parameters, and even to cancel the project outright if it seems necessary. Thus, death marches are not a failure of methodology but a failure of project governance.
Although there are still many organizations that will continue death march projects even in the face of evidence that the project will fail to achieve the intended business goals, few of them are profitable and essentially all of them have other bad management habits. In the words of Eric Bogle, “… year after year, their numbers get fewer. Someday no one will march there at all.”