Project Plans in Excel - Adding Dates

In the previous post in this series I described how to use Conditional Formatting to create a neat and simple Gantt chart alongside a simple Excel-based project plan. In this post I’ll describe how to use dates in addition to the day numbers that were featured in the previous post. The picture alongside (right) shows the result from today's post.

As with the previous case, I’m going to describe a quick and simple method. This method also takes weekends into account as non-working days. We ended the last post with what you see alongside (left).

So, let’s begin by adding the date for day 1 into cell F1. I'm typing “22/2” to represent 22nd February). It’s not readable in the small width of the cell, so we’ll go to the Format Cells window (you can use Ctrl-1 to get there quickly) and select text orientation as 90 degrees. Then, to get the date format that we want, we’ll stay in the Format Cells window and specify a custom number format of “dd-mmm (ddd)”. If the height of row 1 doesn’t automatically increase for you, just do it manually. You should have a result like this:

NOTE: New Course in India: Best Practices in SAS Statistical Programming for Regulatory Submission

Having successfully conducted his long-titled course in the USA, Netherlands, and online, my friend Sunil Gupta is considering the possibility of running it in one or two cities in India. While the schedule is not yet finalised, the favoured period for the two-day class is around April end/early May in Bangalore and maybe Hyderabad.

For further details of the course, see the overview of the online version. To register interest in the Indian course(s), email Sunil directly (and tell him NOTE: sent you!).

You might also like to know that Sunil is presenting his "Preparing SAS Programmers for the Pharmaceutical Industry (An Introduction)" course as a pre-conference course at SAS Global Forum (SGF) 2010. There may still be places available.

NOTE: The Missing Semicolon Just Arrived

Systems Seminar Consultants' newsletter (named The Missing Semicolon) is always a good read, so I was pleased to get notification of the Winter 2010 issue last week. Featuring a mixture of topics, this issue seems to focus on writing good documentation (program documentation and system documentation). Please don't view this as a switch-off topic! Read the articles and you'll better understand the benefits that properly targeted and focused documentation offers.

However, I do strongly disagree with the author's rule of adding a comment to every line of code. Programming standards always give rise to a strong degree of discussion, but in my opinion slavishly putting comments onto every line of code doesn't add anything to the reader's knowledge of the code. Indeed, in the example code given, the vast majority of on-the-line comments are stating the obvious. Comments should describe what is not obvious in the code - that typically means describing what blocks of code are doing and/or why a particular approach was taken (and why other approaches were considered but discarded).

The issue also offers a review of The Little SAS Book (by Lora Delwich and Susan Slaughter whom I featured yesterday), and a nice tip regarding the INFILE statement's MISSOVER parameter.

I recommend you hop over to Systems Seminar Consultants' publications page and a) sign-up for a free subscription, and b) take some time to browse through the archive of issues.

Project Plans in Excel (simple, quick and effective)

For any piece of work other than the smallest, it’s worth planning. Planning doesn’t have to mean creating a huge monster in Microsoft Project - I find that Microsoft Excel (or similar) is often sufficient (and a lot more accessible to the team). This post (and the series of posts that follow) describes how to quickly and efficiently create an adequate plan for small to medium sized projects.

I don't expect all developers to be expert project managers, but I do expect my team members to understand the role of the project manager, to know how to work to a plan, and to focus on delivery. And I do expect developers to run their own (small to medium sized) projects from time-to-time.

A project plan can consist of just a list of tasks (preferably with start and end dates) together with the name of the person who will complete the task, but this can be made to communicate a lot more if you can deliver a Gantt Chart too. The name “Gantt Chart” sounds challenging to anybody who hasn’t met one before, but actually it’s rather simple format that most people are familiar with (often without knowing the name). Gantt Charts can contain a lot of detail and embellishment, but I’m going to describe how to create a simple yet communicative chart very quickly.

NOTE: Informats and Enterprise Guide 4.2 (beware)

I'm a keen follower of Susan Slaughter's books (in conjunction with Lora Delwiche) and her Avocet Solutions web site. The web site is very nicely structured and contains a wealth of solid information. Last week, the Little SAS Book Series featured an article about informats and Enterprise Guide 4.2. The article highlighted useful, user-friendly features of EG 4.2's Data Grid, but also warned of the fact that said Data Grid ignores informats.

The site and the article are recommended reading.

Encourage the (New) Conference Speakers

Reflecting further on the unconference & BarCamp format of the Analytics Camp NC event that I mentioned last week,  whereby sessions are proposed and scheduled each day by the attendees and based upon pitches from the potential speakers, I realised that this is a good means of giving feedback to potential speakers and thereby encouraging new speakers.

It's a little daunting to write a paper and send it off to some anonymous conference organiser in the hope that you might be seen to offer something of interest to fellow conference attendees. And I've recently seen at first-hand how conference organisers can be dismissive of those whose papers are not selected (to the extent of not even bothering to tell them that their paper was not selected). To get some constructive criticism out of them, in order to do a better job next time around, can be like getting blood out of a stone. People who have had papers accepted for conferences on previous occasions will not be put off by such behaviour; however, for a first-timer the anonymous rejection can easily put them off of ever submitting a paper again.

By contrast, the atmosphere at Analytics Camp seems to have been very informal and welcoming. It sounds like just the sort of atmosphere where a novice might be tempted to propose a topic and be given positive encouragement to proceed with their idea.

I continue to warm to the unconference & BarCamp ideas and ideals. More importantly, if you're organising a conference, please be sure your section chairs show respect and offer encouragement for all of those who take the time and effort to prepare a paper and submit it. For conferences to thrive they need a regular influx of new thoughts and ideas; don't stifle and discourage first-timers.