Time Management for IS Professionals

Most IS projects (if not all) work under severe time constraints. Our optimism in estimation is without bounds. Therefore, it becomes crucial that, as IS professionals, we manage our time as best we can.

There are a number of time management methodologies out there. One such example is the FranklinCovey Focus method. This can be used with paper or Outlook as the implementation device. There are other time management gurus as well -- for example, Julie Morgenstern.

I am currently using the Getting Things Done (GTD) methodology which seems to find favor with a number of IT professionals. This method is described in a book of the same name by its author, David Allen. The book is a tough read -- he's stretched into a book what could have been described in a couple succinct pages. Nevertheless, the methodology is both useful and easy to implement.

David sells on his web site an eBook on how to implement GTD with Microsoft Outlook. This is worth a read if you're into using Outlook as your planner. The option I follow is to use GTD in plain paper. David has a free article that describes how to do it. The advantage of paper is that you're not beholden to a computer. Plus, you can track both work and personal life in the same planner. I could do that in Outlook, except I'm hesitant to put my personal task list into the Exchange server at work.

The great thing about GTD paper planning is its extreme low cost. My cost for all materials has been about $10. The recurring cost is about $1 each year for filler paper.

Ultra-Brief Review: Heads First Software Development

I just finished a quick read of Heads First Software Development. I both liked the book and was also disappointed by it.

What disappointed me was that the book has a very ambitious title... it promises no less than a complete overview of the software development process. What it does in fact deliver is a very focused sliver; one way of delivering custom built software of low to medium complexity.

I really liked the book as an introduction to agile/iterative software development. There is a lot of good material about many of the buzzwords du jour: user stories, iterations, various testing methods, continuous integration, velocity and the like. For a manager or a developer trying to understand how to write software iteratively as part of a small team, this is a great book.

The book stumbles in addressing other software methods: for example where the architecture is likely to be highly complex, how does the team deal with architecture? Is there an upfront architecture phase? The book seems to recommend the "architecture by accumulation" approach, where the architecture evolves out of a number of small on-the-spot decisions and not a coherent, properly thought through phase.

The book takes a simplistic view of capturing requirements as user stories and then getting the team to estimate based on a very limited understanding of the user story. I have found that in the complex software systems I've delivered, requirements need a lot more than a sentence, or a couple on a 3x5 card to document. Furthermore, estimation of the requirements is not a straightforward "x number of days" approach, but is broken up by discipline, based on very specific detailed requirements, and a range rather than a single number.

My concerns notwithstanding, I would recommend the book, with the caveat that the reader keep an open mind about the possible circumstances into which the advocated methodology will fit, and also read, for example, SPSG to get a different perspective.

Personal Productivity for Project Managers

I've built a personal productivity framework based on three components:
* Microsoft Outlook
* OneNote 2007
* Getting Things Done

Outlook is the standard issue email client for most large companies. So I won't dwell on it too much at this point. I would advise the interested Project Manager to check out its task management features -- most people I know make little or no use of the task management area.

GTD is a wonderful framework to manage your workflow in a very high traffic environment where you receive and process hundreds of email messages. As a methodology, it is more workflow management than time management, though most people use it for time management. Further information about the basic GTD framework can be had from the canonical book, Getting Things Done. The author of GTD also has a monograph on how to use it with Outlook that he sells as an eBook. I recommend that the interested GTD user purchase and utilize this -- setting Outlook up is quite easy to use. Of special note is that GTD can be made compatible with PDAs and SmartPhones from either Palm or one of the many Microsoft models.

OneNote is the third leg of this efficiency stool. I have a OneNote book divided into multiple tabs. My tabs are as follows:
* Daily standup meetings
* Customer/User Notes
* Manager Notes
* Team Member Notes
* Issues
* Deployments
* Other

There are two features in OneNote that make it virtually indispensible to the project manager: the first feature is automatic saving. In other words, you don't lose the last half hour's work if you've forgotten to save, and your PC crashes during the middle of a meeting.

The second feature is the ability to create tables very easily. Unlike Word, you don't need to pick a menu button to create a table. An easy way to create a table with three columns is to type the title for column 1, followed by a tab, followed by the title for column 2, then followed by a tab, finally followed by the last time. An enter begins a new row.

The key to success with this framework is for the project manager to take their laptop with them to every meeting, and be prepared to take notes on the fly.

Expectancy Theory of Motivation

When you want to motivate a team member to achieve a specific outcome, expectancy theory can help you in validating your motivational approach. A good description of expectancy theory can be found at http://www.uri.edu/research/lrc/scholl/Notes/Motivation_Expectancy.html.

Expectancy theory has three components:

• Will the desired actions lead to good performance? (e. g. "If I work 60 hours per week for the next three weeks, will that lead to a successful completion of the project, or is it wasted effort?")
• Will the good performance lead to a desired outcome? (e.g. "If I work really hard and this project is successful, will I be rewarded at the end?")
• What is the value of the desired outcome to the individual? (e.g. "If I work really hard and make this project successful, I may get a 3% raise where otherwise I would have got a 2% raise. Is the extra effort worth the rewards to me?")

Keeping in mind the three components of expectancy theory provides the project manager a tool to understand the right approaches to motivation of team members. Because many of the valuable desired outcomes are not under the direct control of the project manager (e.g. salary raises, bonuses, time off, etc), line managers will need to closely support the project manager in the motivation of team members.

Where project managers are not empowered to provide motivational outcomes, team motivation suffers, it is usually the poor project manager who gets blamed for it. In reality, creating the right conditions for a motivated team is a shared responsibility between the project manager and the line manager, working together.

Make your team happy

Buying your team coffee and donuts every once in a while is a nice gesture. While nobody is going to work extra hours in sheer gratitude for your generosity, it does show the team that you care for them, and over the long run actions that show caring and sincerity are usually reciprocated by a team that shows caring and sincerity to the project and the project manager.

The corporate culture needs to provide some budget to a team, under the project manager's control, to be spent on team celebrations. Coffee and donuts one week, icecream another, a box of chocolates on the third; these are miniscule compared to any non-trivial project's run rate. Yet in this day and age, it is surprising how many companies will not buy their teams a cup of coffee, yet think nothing of hiring consultants with billing rates over $2000 a day for staff augmentation.

Truth and candor on projects

Why would I make such a big fuss of something as obvious? Its because I've seen experienced, well-meaning people break this rule so many times. This can take one of the following forms:
The project is falling way behind target, and the project manager is afraid of telling the truth. He resorts to telling the client that all is well while praying for a miracle to occur. Bob Wysocki calls this "hope creep".

The project manager sees telling the truth as an admission of failure and spins the situation in any of a thousand different ways. The more vicious ones find a scapegoat -- either another person or a linked project that is blamed as the cause of the delay.

The customer is pretty smart, and can inevitably figure out when your nose is growing longer. The customer may be irritated when you tell her that her project is going to take longer; but that is nothing compared to the harm you cause your credibility if you're caught lying (and all liars are eventually caught). It takes some time and savvy to both tell the truth and survive long enough for the customer to know and appreciate your straightforward nature. But once the trust is built, it becomes a very powerful force in your favor.

Modeling overhead tasks in Microsoft Project

Here's a little paper I wrote on how to model overhead tasks in Microsoft Project. Enjoy!