Hiring Programming Staff (Part 2)

Note: this article is split into two parts due to its length. The two segments are related, but each can be taken as a stand-alone article. Part 1 deals with phone interviews, part 2 focuses on testing.

The Programming Test

The ability to hire good programmers isn’t a skill generally associated with a project manager, but if a project manager isn’t sourcing coders, who is? It’s likely that it will be senior management or HR. Senior management should definitely be involved in the selection process, but hiring new programmers is best done in conjunction with someone coming from a technical background.

So what is the key to finding that great programmer? Testing. Giving a candidate a written programming test is the only true measure of their capabilities. The main things to look for are competence in the languages you develop in, be it .NET, PHP, Java or whatever. In addition, logical and deduction skills are a must.

If I was asked to give my opinion on what the single most important attribute of a good programmer is, I wouldn’t be able to answer. That is because its a minimum of two qualities. They are; ‘is smart’ and ‘gets things done’ (see The Guerrilla Guide to Interviewing by Joel Spolsky). Of course, there are many other favorable qualities to look for when adding to your technical team, traits such as: attitude, communication skills, how well they fit into your office culture, etc. But if you don’t have both ‘smart’ and ‘gets things done’, all bets are off.

What does ‘smart’ and ‘gets things done’ mean? I will try and explain what these traits mean by presenting two fictitious examples:

Tony is a university graduate who loves to talk technology. He spends a couple of hours each day chatting with the other programmers about how AJAX is going to bridge the gap between traditional desktop applications and the limitations of the web. There is no doubt Tony is a smart guy, but if he’s spending so much time theorizing about technology rather then doing it, not much is going to get done (i.e. he is smart but does not get things done).

Sarah is a dedicated programmer who appears to be a model team member. But after a number of project postmortems, it becomes apparent that approximately 50% of all bugs are attributable to her (this is out of a team of 5 programmers). This taken together with other anecdotal evidence points to a pattern; Sarah is lacking the fundamental skills required by a programmer. She is ‘getting things done’, but the quality of her output is very low.

Now onto the test. It shouldn’t be too long, about 5-6 pages at most. It shouldn’t take a candidate more then an hour to complete. The questions are divided into a number of categories: logic, programming, SQL, JavaScript, XHTML/CSS, and people skills.



Logic questions - these questions set out to test a candidate’s reasoning and logical deduction faculties. Some would say that these are the most important questions in the test because they are a strong reflection of a person’s capability to think in an abstract manner (and therefore tackle any kind of programming or technology problem thrown at them). I even know someone who immediately terminates the interview if the candidate fails these questions. An example question would be: “if I asked you to build me a house, how would you go about doing this?”. A correct answer for this would be along these lines: “I would begin by ascertaining who the house is for, what sort of budget is available, if their are any time or material constraints. Once that is done, I would organize the contracted labor to undertake the work, ensure proper planning permits are obtained, ...”. What you are trying to gauge is if a person is thinking the problem through in a systematic sequential manner. Other questions could be: “How many petrol stations does the city of Melbourne require?” or “How much does the Golden Gate bridge weigh?” With these questions, there isn’t really a correct figure, the point is how did the person derive the figure, and what logical process did they use to get there?

Programming questions - these questions will be specific to the development environment you use, but an example would be; “Using .NET/C#, write a function to find out how many words are in a sentence”. The coding questions shouldn’t be overly hard as many programmers are reliant on reference material. A candidate’s response to such a question will make it clear whether they have used that language or not. Another good question is to present a slab of code which has a bunch of bugs in it, then ask the candidate to locate the bugs. These questions are where you will spot the above average programmers; where one programmer writes 10 lines of code to do something, another writes a one line regular expression or uses recursion (obviously the better choice). You would also be on the look out for error-checking and optimization.

SQL – I don’t believe you need to ask a super complex SQL question involving inner joins or embedded SELECT statements (especially since many IDEs generate SQL these days). The point is to determine whether they understand the basics of SQL. A question like this would suffice: “write a SQL query to return the surnames of all the people under the age of 30 shown in the above table. Ensure the results are ordered alphabetically.”

JavaScript - you want to check for a basic understanding of JavaScript. A simple question such as this will be fine: “Write JavaScript code to check that a user has entered a value for the Username and Password fields. If not, present an error message to the user”. Again, it will be very obvious if the candidate has never used JavaScript before.

HTML/CSS - you need to determine that a person has a fair understanding of HTML and CSS. I would do this by presenting a few short snippets of unrelated HTML/CSS code. I would ask the candidate to say what each snippet does and also to correct or improve each one if needed. For instance; a basic image tag with no alt attribute (nb. the alt tag is required).

People skills - the question I generally go for is this: “You’re the only one in the office when a client you’ve never dealt with rings. They say in an aggressive tone; ‘my website is down, I was told all the problems with it were fixed, what the hell is wrong with you people?’ Considering you know nothing about their project, what would you say to them?” A good answer would include these key statements: allow the client to vent, apologize for the inconvenience, empathize, tell them you will look into it immediately and call them back in a half hour, etc. Having a candidate answer well on this question is really just a bonus. Personally, I would still take a candidate with superior programming skills over someone who has good ‘soft skills’ (after all, coding is what you need done). But this may be a distinguishing factor if you have evenly matched candidates. You never know when you may have to send a programmer out on site or have them gather requirements from a client.

One thing to look for is how well a candidate has followed instructions, have they read the question properly? Have they answered it exactly or did they get off track? Obviously a person’s ability to read and follow written instructions accurately would be a tremendous asset at any organization.

I have come across a few other ideas for improving your chances of nabbing a great programmer. Personally, I have not tried all of these approaches, but they do seem like sound pieces of advice. One suggestion is to look for programmers who do coding on open source software.

A person’s involvement in the open source community is a reflection of their commitment to the computing industry (i.e. they don’t just code for the money). Obviously, you would want to investigate what their contribution is; for instance, if you were especially looking for a UI designer, then UI design is what they should be doing on the open-source project.



Another approach is a trial period, where you bring a programmer on-board to do a small segment of coding on a project, for perhaps 24-48 hours. I doubt they would make much of a contribution to the overall progress of the project in such a short space of time, and in fact would probably reduce productivity because of the hand-holding required, but what it will reveal is how they interact with other team members.

Project Status Reports Everyone Can Understand

Creating basic highlight reports which clients and management can comprehend.

Letting people know how a project is coming along is obviously a key responsibility of any project manager. With so many methodologies to choose from these days, it becomes hard to determine which key pieces of information will be useful to those involved in the project. These methodologies often come with a tangled mass of cryptic terminology, often only recognizable to practitioners of the system (e.g. burn down chart, sprint backlog, concession, story points, etc).

Let’s say for instance your client is in the food transport business and is getting your company to build them an ERP application. Chances are they wont understand concepts from Agile or PRINCE2, and why should they, they are in a totally different industry.

The issue then becomes; what information do you present when creating a status report that will be useful to the broadest audience (e.g. client, senior management, non-technical user advocates, etc). The project information maintained internally for planning and day-to-day management is one thing, but what gets shown to non-technical stake-holders is something entirely different. Of course, the details going into progress reports will most likely be derived from the project tracking documentation (e.g. number of bugs held in the issue log, tasks remaining as shown by the project schedule, etc).

So what kind of information will a non-technical audience understand? The simple answer is percentages and bullet points in plain English (with no methodology specific jargon).

Here is an example of a Project Status Report (or Highlight Report as its known in PRINCE2). I send these to clients and senior management via email on a weekly basis (generally on Friday afternoon):

Hi Tom,

I wanted to provide you with a brief summary on how your project is progressing:

• Your project is currently 65% complete.
• 100% of all tasks in the design phase have been completed.
• 70% of the tasks in the coding phase are finished.
• The project management phase is 45% complete.
• The quality control phase is 10% complete so far.
• 35% of auxiliary tasks have been completed

Our bug log is currently tracking 3 unresolved bugs (1 of which is marked as high priority). The bug log also holds 3 feature additions pending approval.

We have just uploaded the latest work to our staging server for you to review (this can be viewed by following this link: http://www...).

The next thing we are planning to work on is the photo gallery component, we are aiming to have this completed by late next week (12/Dec).

We are still waiting to receive media release articles from your PR person. Without these, your site will launch and this section will be blank (or have to be hidden initially).

Let me know if you have any questions, I will be happy to answer them as best I can.

- LM

The email subject would be something like ‘RE: Blue Widgets, Project Status Report’.

The structure of the report is as follows:

Bullet points - the first bullet point is always a percentage saying how much of the overall project has been completed. The remaining bullet points give a percentage completion on the various phases of the project (you may have different naming conventions, but that’s OK). Will the client really analyze these figures closely and go “yeah, yeah, auxiliary tasks, 35% complete, awesome”? Probably not. So what’s the point of listing all these stats then? It’s more about the effect it will have, it will give people the feeling that you have your finger on the pulse of the project, that you know exactly where it’s at. This translates into confidence that the project is being managed in a predictable fashion.

Bug summary - a very brief run-down of where you are at with logged issues. You may want to include some information on how many bugs were closed this week, or how many feature additions are waiting approval. This demonstrates that you are dealing with the inevitable issues that will arise on the project in a systematic fashion. I should make a point regarding the discussion of bugs with clients; there are different levels of disclosure senior managers find acceptable. Personally, I like to be very open with this information, but I suggest you ask management about how much ‘bad stuff’ you are allowed to reveal to the clients.

What we’ve just done - a description of any major movement made on the project since the last update. This could be the addition of a new module, completion of a documented milestone, anything which says “we are really getting places now”.

What we are planning on doing next - this is pretty straight-forward, but is helpful because it gives the client (and management) a heads-up on what you are about to start working on. The client may suddenly say “we thought you were doing the billing module next?” or “we need to change that around, we prefer you work on... next”.

Any problems that occurred or may occur in the immediate future - this doesn’t necessarily have to be a gripe or panic zone, who knows, maybe your project is running 100% smoothly (unlikely, but you may be the first). This area can be used to give the client a polite nudge (e.g. “we need ... from you, or else this will happen”). Again, caution should be exercised about what ‘bad stuff’ senior management allows you to disclose to the client.

Also notice that the statements in the report are very brief, to the point, no longer then two sentences. This just comes down to being respectful of peoples time. Everyone in corporate life is very busy, no one wants to read long emails.



The format of the status report I have presented here is very basic. I wouldn’t suggest that Gnatt or Burn-down charts aren’t useful, just that the information contained within these or any other management tool needs to be converted to plain English before being given to clients.

Outsourcing Coding vs Building an In-house Team

Perspectives on using outsourced programmers in a web development environment

A few years ago I was in Bali for a fitness bootcamp. Whilst watching TV late one night, I came across a documentary on the construction of an underground railway system in Amsterdam. I vividly recall one of the engineers being interviewed saying “it’s impossible, but we’re going to do it anyway”. When I think of some aspects of outsourcing, I remember this statement because there definitely are some tough challenges in getting outsourcing to work, but I believe it can be done.

I should begin by saying that by no means am I an authority on working with outsourced programmers, in fact, I’ve only done it for a few months total. My brief experience with outsourcing revealed both good and bad aspects of the approach, but more importantly, it opened my mind to the possibilities. I have noticed that some people seem to be against outsourcing for personal reasons, and that is surely their prerogative.

In some ways this article is a retort to a piece on outsourcing I recently read. The article in question is by Michael Bean and is titled The Pitfalls of Outsourcing Programmers. It is one of the selected works gathered together in the book The Best Software Writing I – Selected & Introduced by Joel Spolsky.



Am I attacking what the author had to say in the article? No way, it’s very well written and full of insightful information. Some knowledge of what the article is about is required in order to understand my perspective on the matter. I don’t want to re-write the article, so I will just cover the main points very quickly.

Michael Bean discusses the following ideas:

There has been a rush in recent years for US companies to send development tasks to India, China, and Eastern Europe.

Software development is design not manufacturing. Therefore, by virtue of its creative nature, it’s not something which should be sent off-shore.

People pay for ‘value added’ services or products. If all aspects of a company’s offering (from production to customer service) are outsourced, they cannot give customers what they truly desire.

Outsourcing customer service is equivalent to saying you aren’t interested in hearing what you’re clientele have to say.

The motivation behind setting up a massive IT work force overseas goes like this; “if Nike can do it with shoes, we can do it with code”.

The “but you are taking away jobs from Americans” argument is spurious at best, people in India or where-ever have just as much right to work as anyone else. We are living in a global economy after all.

When a business outsources innovation related task, they give away their competitive advantage. Over time, a company will lose their capacity to innovate.

Innovation suffers when people are spread across different countries since they can’t communicate effectively.

Outsourced programmers aren’t around for the long term. They tend to disappear after the project is over, taking with them any specialist knowledge they have acquired.

Completely outsourcing all of your development is a bad idea (i.e. both design and coding of the software).

The difference between United States and Indian time zones means there is no overlap between their working hours. This makes communication even more difficult.

Creating software is more about design then assembly. The ability to design is also considered an uncommon skill.

This is basically the crux of Michael Bean’s article. I’ve done my best to retain his core ideas, but obviously there is the risk of misinterpretation.



I have to agree that it is undesirable to outsource everything (i.e. both design and coding). In Michael Bean’s article, he doesn’t really go into what he means by design. To me, design means the functional specification (i.e. how the software will work from the user’s point of view).

Would I trust an outsourcer to write a functional specification? No. This is not meant as an attack on the skill of overseas programmers, it’s just unreasonable to think you could get a remotely accurate spec without meeting a client face-to-face. Would I trust outsourced programmers to create software based on one of my specs? Yes, definitely.

The other problematic aspect of Michael Bean’s article is that it doesn’t explicitly mention a division between shrink-wrapped software development and custom software projects. This is a major consideration. If you are trying to minimize production costs, then outsourced programmers are very well suited to custom development (and yes, maintenance is a big issue, but it’s a big issue with normal companies anyway). Reducing operational costs may be a very real concern if your business has investors or venture capital.

There are strategies for having outsourced programmers work on shrink-wrapped software, for instance; some Indian companies offer dedicated teams that only work on your software, they even come complete with their own dedicated project manager.

It’s true, you’re communication will take a hit, that is unavoidable. But you don’t get something for nothing. If you want to produce software for 50% of the normal cost, then be prepared to put up with some discomfort.

Luckily, in Australia we don’t suffer from the same time zone issues our American friends have to endure. In my experience with Indian programmers, I found they began to stir at about 12 noon, that’s just fine as far as I’m concerned.

Communication and project management tools are very important for successfully working with outsourced programmers. MSN or other instant messaging software is the key. I remember having three different IM softwares running on my computer at one point in order to keep in touch with everyone on my projects. A project management tool like Basecamp is also very helpful. A bug tracking system is another great idea, and an online schedule that can be viewed by everyone will make life a lot easier.

Perhaps this is a little simplistic, but it seems to boil down to this: outsourcing results in cheaper software development, but in-house teams produce better quality software.

Rescuing a Hopelessly Derailed Project

Perspectives on the maladies that befall an overdue project.

A sobering reality of the software development industry is that projects sometimes run late; most of the time it’s not the end of the world, although this view is not held by all (the word ‘late’ seems to be a very dirty word in the business world).

In the grand scheme of things, a project arriving one week late generally has no significant impact. Of course there are exceptions, for instance; a project may need to be delivered to coincide with a client’s attendance at a tradeshow. The kind of late project I want to deconstruct in this article is the hopelessly derailed type, generally running months behind schedule, with an irate customer banging down at door.

The causes of a hopelessly derailed project are many and varied, but the particular focus of this article is the inherited late project; this is where a newly appointed manager must pick up the pieces of a disastrously run project. Thrust into the midst of customers screaming for blood and management demanding results.

If you are a project manager finding yourself in such a situation, first and foremost you must be resolved that you may fail despite your best efforts. As the saying goes; “fortune favors the bold”, so if you can’t accept the risk, then you should not accept the challenge. This also extends to the possibility of being made a scapegoat. I don’t believe there is a level of intrigue functioning in an office where upper management ‘sets people up’ for a fall, it’s just businesses don’t like losing money. In a corporate environment, taking on greater responsibility often comes with increased salary, but if things don’t work out, your head is for the block.

In order to steer a lost project back to safe waters, a view for the long haul needs to be adopted. This seems logical since no one would be worried if only a small amount of work was required to fix a troubled project. On one occasion I worked at a client’s office for 8 months straight in order to launch their ERP application. I also have heard of instances where developers toiled for almost a year to save a late project.

Assuming you're OK with the risk of things still going pear-shaped in spite of whatever efforts are brought to bare on a late project, the following course of action is what I would prescribe (note: not all these strategies are appropriate to all projects);

Use a bug tracking system - installing and using a bug tracking system is going to be an excellent start. It will allow you to regain a semblance of control and take stock of the situation. It’s unrealistic to think a complex system can be understood immediately as a whole, so 'chunking' it often helps. A bug tracking system allows you to compartmentalize problems. Once an inventory is taken of all existing issues, distribution of tasks amongst technical team members becomes a breeze.

Realize the political obstacles are greater then the technical - on a late project there are both technical and political challenges to be overcome. The technical issues generally aren’t as bad as they may first appear, especially if a senior programmer is on hand or the project manager has a technical background. The political difficulties are trickier because they are less obvious then an error on a particular screen. It’s like being at the helm of a ship that’s gone off-course, lost in the middle of the Bermuda triangle. The biggest challenge is often re-establishing client confidence in the project (e.g. client: "these cow-boys don’t know what they are doing!", "they promised me this and didn’t deliver", "I have no confidence in these guys any more.").

Stem the tide of negative sentiment - apologizing to the customer for the poorly managed project is a good start, a bitter pill to swallow but necessary for re-establishing trust. Stating to the customer in concrete terms what is being done to correct the problems on the project is also helpful. For example, something along these lines: "I’m sorry about the delay on your project, I’m working to get it back on track now. I’ve looked at the project history, and personally, I would be angry too if I was paying good money for this system. The first thing I’m going to fix is...". Making such a statement means there’s no turning back as responsibility has been taken for the project; its all or nothing now.

Feature freeze - a common and sensible strategy is to stop adding new features. In reality, this may be easier said then done. It’s possible that agreeing to some new features requested by a client can help re-establish report, a demonstration of your willingness to listen. From a technical stand-point, adding features to an already late project doesn’t make sense, but from a political perspective, it may be a step in the right direction.

Understand the business domain - reading through any requirements documents on hand is going to be vital. Arriving late on a project is a massive disadvantage because it’s hard to know what was originally discussed. As the saying goes; ‘the devil is in the detail’. This is exactly what sunk me on a late project I was meant to salvage. Everyone was on edge, and I missed a minor requirement. At the time, it wasn’t a big deal and could of been corrected easily, but politically speaking, it was the straw that broke the camels back. One strategy which may help is to work from the client’s office for a few weeks, at least until some semblance of stability returns to the project.

Consider adding some new features - a late project isn’t exempt from this old business maxim ‘time is money’. The client has paid for something which isn’t right or has not been delivered on time. Your company has expended resources working on the project, possibly having used up all the available budget. Continuing work on the project could mean your company is losing money. This is where allowing the late addition of new features can make sense. People will say not to add features to an overdue application, that stabilizing the project is the number one priority, but adding new features can be a politically prudent maneuver. Senior management will likely be pleased that new money is coming in for billable off-spec work, but programmers probably wont share this enthusiasm.



Overtime wont fix everything - I’d recommend against project managers or coders working ridiculously long hours, but an additional couple of hours each day can make a positive impact on a late project. If people normally leave the office at 5pm, departing at 6.30pm-7pm instead is reasonable. People can consistently maintain an hour or two of extra work per day for many weeks without sacrificing the quality of their work or their sanity. Working until 9pm or 10pm every night and on weekends will result in burn-out within a few weeks. After that point, extra time on a project is doing more harm then good. In the unlikely event that senior management takes issue with this point, a decision needs to be made; do as they ask (i.e. work more hours), or say something along these lines; "I’ve already committed a few extra hours each day to work on this project. I’m here for the long haul and I’m going to get this project done. But I’ve reached the limit of how much extra time I’m willing to put in. There are other commitments outside of work I need to keep too." Unfortunately, taking such a stand in some organisations can have negative consequences. By no means am I against working hard for a worthy goal, I am merely saying the effort needs to be weighed up against what you are going to be sacrificing (e.g. health, family, etc).

Get movement on the project - I have come across suggestions that when first arriving on a late project, the best thing to do is “stop and write a spec” or “stop and do this or that...”, I believe this is unrealistic. The project is already stagnating, the last thing senior management or the client want to see is a complete halt, they want to see progress! I have been in a situation where I’ve told a client “we need to stop coding for a week or two so I can write a proper test plan. Otherwise the bugs will just keep coming.” It’s not that the client didn’t understand the importance of this, it was more an issue of cost; who was going to pay for this time? The client wasn’t willing to pay for the lull in development, nor was the company developing the software. Needless to say, the bugs did ‘keep coming’. It’s important to get some small wins happening so things can get moving in the right direction again. This could come in many forms; for instance, clearing all currently logged bugs, stabilizing one particular module within the system, etc.

Map-out tasks ahead of time - a project manager needs to work-out what programmers are doing ahead of time, having programmers waiting on a project manager to give them work is tremendously inefficient. For a technically-oriented project manager or senior programmer, this will generally mean they get to do less coding or technical work. The best way to map-out tasks is by maintaining an up-to-date schedule which lists pending tasks and who’s responsible for them. Programmers should always know what they’re working on after they finish their current task. There should rarely be a time when they ask "what do I work on next?", they should already know.

Build-in recovery tools - sometimes to achieve a goal or solve a problem, an indirect route is required. For example; it may take 12 hours to track down and fix a particularly troublesome bug. Instead of doing this, it may take only 2 hours to code in a corrective utility which solves the problem for the time-being (yes, this is sort of a ‘hack’). Time and momentum are of the essence on a late project, and unfortunately bandaid fixes sometimes make the most business sense, especially when software has recurring problems which are hard to pin-down.

Be observant of the client’s mood - it’s important to demonstrate you are on the client's side. For example, the client may say "this product is unacceptable", you could respond with "I agree, I wouldn’t be impressed If I were in your position either. All I can tell you is I’m focusing on it now and wont rest until you’re happy". When report is re-established with a client, they may even help shield you from pressure emanating from other stake-holders on the project.

Lead by example - programmers have no reason to become emotionally invested in helping to correct a hopelessly late project, and why should they, it’s management that got them into this mess after all. But programmers may care if it becomes about comradery or delivery of a product they can be proud of. For instance; a project manager may tell the programmers "I’m staying back a few extra hours to work on the project. I’d appreciate your help if you’re willing to give up your time." Or "I know its not our mess, but we're going to clean it up anyway. I want to get our customer the best good quality software we can". Emotive rhetoric is useless if it's not from the heart, people can spot a phony a mile away and wont appreciate being manipulated.

Many suggestions made by other project managers on how to fix an ailing project assume a fairly high degree of power to affect change (e.g. “say no to new features” or “stop the project to restart it properly”). In reality, chances are the project manager is joining the late project already hamstrung. If it’s a senior programmer that’s been tasked with correcting a failing project, they will traditionally have much less power to affect change then a true manager. This doesn’t mean “give up, don’t try”, it just means a lot more creativity and soft skills will be required (i.e. people skills).

I’ve also come across people who say its better to bail on the project and ‘run for the hills’. I have had experiences where it was possible to fix a hopelessly derailed project, and some which could not be salvaged to everyone’s satisfaction. It’s really a personal choice whether to take up the challenge or not.

The Scourge of Unnecessary Meetings

Tactics for reducing time spent in unnecessary meetings.

As a project manager that used to be a programmer, I can recall how much I loathed sitting in meetings. My train of thought was commonly along these lines; “why am I in this meeting talking about the project when I could be out there coding it?” Because of this, I do my best not to subject programmers to meetings unless it's absolutely necessary. Obviously not all managers come from a technical background, so this empathic understanding may not be present.

Ad-hoc meetings are a growing trend, but its not always convenient for three or more people to stand around discussing the details of multiple projects in an open-plan environment. When it’s realized that an impromptu discussion is probably disrupting other people around you, the common suggestion is “lets take this to the boardroom”. Now you have an ad-hoc meeting which has become the real thing, a meeting which can potentially turn into a lengthy discussion.

This brings us to the topic of written agendas, some swear by them, but are they in keeping with the spirit of Agile? Having someone write up an agenda is added bureaucracy. For short meetings at least, I believe agendas can be substituted with presence of mind and self-discipline. You need to be able to say two things in a meeting without being viewed as negative; “we’re getting off track here” and “we need to move on to the next item”.

Ideally, a project manager should do everything they can to shield programmers from meetings. If operational management is going directly to programmers for project status updates, then the project manager isn’t being allowed to do their job properly. It is not unreasonable to expect a project manager to know exactly how a project is progressing at any given point in time.

How does a project manager keep abreast of project status? Simple, by maintaining a project schedule which programmers go into 1-2 times per week and update their particular sections (e.g. when Jane finishes the validation for the sign-up form, she marks the task as 100% complete). Most other situations can be handled as one-on-one meetings, by email, or via MSN.

The only time all programmers need to be in one room at the same time is when they all have to talk to each other. Senior programmers must bare an additional burden; they are commonly needed in meetings to provide technical expertise.

Development team meetings are an exception; by this I mean meetings with nothing but programmers in them. These meetings are rarely superfluous, programmers will be itching to get back to their computers and continue with their work so they wont waste time on unnecessary matters.

I hear you saying “but if you keep programmers out of meetings, they wont interact with other staff and wont know what’s happening in other departments”. You can’t cajole a team to ‘jell’ by putting it into a contrived environment such as a meeting, which is an inherently formal situation anyway.

You’re more likely to build a sense of internal community by organizing events which are obviously social gatherings (e.g. everyone leaves the office at 4.30pm to go for pizza and bowling). Another way is to provide a pleasantly furnished communal eating area where people can sit and chat during lunch time.

I have seen it suggested that coders answer project status queries by saying something like; “it’s in the bug log”, or “it’s on the wiki”, or “I sent you an email about that”. Even if you assume a manager understood the reasoning behind such a statement, it’s still mildly rude at best and politically insensitive. Perhaps a better version would be “I’m happy to meet with you to discuss it, but it is in the bug log. And to be honest, I would much rather be coding so we can delivered sooner”. Would such a statement work? Who knows, but at least it wouldn’t come across as being negative.

Using MSN as a communication tool is a topic of potentially heated debate. Some companies ban it outright, others embrace it and reap the benefits. I have been at one company where everyone had it on their machines and it worked-out just fine.

Admittedly, sending a message like “can I talk to you when you’re free?” to a person sitting three feet away does feel kind of weird. However, walking over and interrupting them midway through a task is likely to break their train of thought or disturb others sitting near by. There is a degree of ‘knowing what a person likes’ here, if you know a person prefers emails, send them emails, if a person prefers face-to-face discussions, so be it, accommodate them.

At the risk of being facetious, I would say programmers love MSN. This is because it offers a degree of control. An instant message can be left for a few minutes without being answered and doesn’t break concentration the same way verbal interruptions do. I’d say MSN is more suited to specific questions like “will the file upload feature be ready today?” rather then vague queries like “how’s the project going?”

MSN is also great for giving simple instructions like “a friendly reminder Tom, I need you to go into the project schedule today and update your areas” or “the client has logged a few bugs, I’ve assigned them to you, go get them when you’re ready.”

The main danger managers see with allowing programmers to have MSN installed on their computer is that they will talk to their friends; and they will, but sometimes you have to take the good with the bad. Personally, I fritter away maybe 20 minutes per day talking to friends on MSN (e.g. “did you go for a ride on the weekend?”, etc). The problem is when the amount of time spent on MSN becomes inordinate (e.g. 2 hours plus), but this is a matter of self-discipline and only occasionally affects some programmers.

Now we come to one of the most disturbing causes of unnecessary meetings, ones which have been called for the sole purpose of stroking a manager’s ego (nb. this may be on a subconscious level). Tom DeMarco in Peopleware calls these 'status meetings'; not because they are about getting the latest status on a project, but because they are about affirming the bosses 'bossness' status within the organisation. There may be little that can be done about this situation, after all, they are the boss right?

I have seen one company where the managing director would have weekly meetings which went for an hour. During each meeting, he mostly talked at people. Programmers said maybe four or five words in total during the meeting, this was a good indicator they didn’t need to be there.



The bottom line is meetings are here to stay, including the unnecessary ones. This is simply a product of a corporate environment, managers are social beasts who like to talk, programmers are technical beings who like to code.

I have seen programmers suggest other approaches for alleviating the blight of unnecessary meetings. For example; require that an agenda exist before accepting the meeting request, insist off-topic items be discussed at another time, keep a log of time spent in meetings to use as ‘evidence against your boss’ when projects slip, etc. All idealistic and pragmatic, but unfortunately whilst the balance of power remains with the managers, the tilt will remain towards verbal communication.

One Minute Goal Settings

Getting quality work from your team members

Most arguments people have with each other are a result of misalignment of expectations (e.g. Bob: “you said you were going to do this...”, Tony: “I never said that!”. Jane: “You promised this...”, Greg: “I never promised that!”).

- Concept from Brian Tracey's book The Psychology of Achievement

A common problem encountered in the workplace is when a team member thinks their responsibility or task is one thing, but their manager has a completely different idea about what they should be doing.

This is where One Minute Goal Settings come to the rescue (or Goal Settings for short). Simply put, its just a one page document which is split into two parts; the first part describes the task to be undertaken, and the second part details the level of quality that is required.

This strategy was developed by Kenneth Blanchard and Spencer Johnson and is contained in their classic book The One Minute Manager. At its core, the idea is that people working together should know what is expected from beginning to end, there should be no surprises.



What’s that I hear you saying? “just fire off an email or put a Post-it note on their desk telling them what you want them to do.” Well, a goal setting document is different in two very important ways; for starters, its a mutual agreement, and secondly, it specifically sets out the level of quality you have in mind.

These are two very powerful things which should not be underestimated. It’s well known that people are more inclined to do something if you ask them rather then tell them. Giving people a say on how they work is very empowering. Getting a person to happily agree to the parameters of a task has so many benefits its simply beyond the scope of this article to discuss them all, lets just say the chances of success go up dramatically.

The second major aspect of a goal setting document is the level of quality expected. Why is this important? Because people can have vastly different ideas about what constitutes quality. A programmer may not even notice a button is misaligned by a few pixels, but to a usability expert, this could send them right over the edge. There’s an added bonus to openly discussing how well things should be done, over time it can actually lift peoples’ quality of work as they are exposed to a higher ideal.



This is a typical scenario of how a goal setting session with me would go:

Louis: “John, when you’re ready, I’d like to go over your goal setting for system testing”

John: “No problem, I’ll just finish writing this email. Say 10 minutes?”

Louis: “Sounds good”

[we go off to the boardroom - goal settings shouldn’t be done around other team members]

Louis: “OK John, I’ve written up your goal setting for conducting system testing on the Widgets Project. I’ll read through it and you can tell me if it all sounds reasonable, if you’re not happy with anything in it, I’ll go change it”

[read through the document – this takes only a minute or two]

Louis: “How’s that sound, does it all make sense?”

John: “You said you need it done by this Thursday, but I’ve got a dentist’s appointment in the morning. Can we make it Friday instead?”

Louis: “Done, I’ll update it and re-print it”

[I adjust the document, re-print it, and come back – this rarely happens by the way]

Louis: “OK, updated, Friday it is now. So you are happy with everything I’m getting you to do, ‘cause you are making a commitment to me on this task”

John: “Yep, all sounds fine to me”

Louis: “Cool, we’re all done. Oh, keep in mind John, before you come to me to say you’ve finished, just be sure to re-read the document at least once to make sure you really are finished, OK?”

John: “Yeah, make’s sense”

[Friday passes and John reports the work has been completed. I review it, its great]

Louis: “Hey John, can I give you some feedback? When you do testing with such detail, it really impresses the hell out of me. You logged 32 bugs, that's 32 bugs the client won't see. Thank you, great work.”

And that’s it, it really is that simple. Assuming you are working with competent and passionate individuals, things will rarely go wrong. If you want to know what the course of action is should things go wrong, I recommend getting the book as it covers the topic in the required detail. When things go right, just be sure to let the person know you are happy with their work.

Do goal setting documents always work? The simple answer is no, there are rare occasions when it’s actually counter-productive to enforce a goal setting agreement. Let me relay an instance when just such a situation occurred.

I was working with a number of programmers at a small web development company where resources where quite tight. I had been using goal settings with success amongst the junior programmers, but a time came when I negotiated a goal setting with the senior programmer to have him produce a coding style guide. Even though I could of produced the guide myself, it was too far outside of my dominion. The style guide was more likely to be accepted and adhered to if it was championed by ‘one of their own’ (i.e. written by a programmer for other programmers).



At the time, the senior developer was under a lot of pressure to deliver on a number of client projects. The agreed date was missed and no style guide materialised. Even though there was a pretext to say “hey, didn’t you say you were going to produce the style guide by the 18th?” in this situation, the value of doing such a thing would have been counter-productive.

I could obviously see that he had been working exceptionally hard to keep other commitments he had made. Also the fact that he was in a senior position in some ways gave him mandate to drop tasks as he saw fit, he is after all a professional with many years of experience, he knows what he is doing.

Management Styles in Web Development

How operations management affects project management in a web development environment

“Fostering an atmosphere that doesn't allow for error simply makes people defensive. They don't try things that may turn out badly."
- Tom Demarco, Peopleware

One of the best teachers I know once let a martial arts student punch a wooden board when he knew it wasn’t going to break (due to incorrect technique). After the student’s failed attempt, he said to the group “I could tell it wasn’t going to break, but who am I to stand in the way of your dreams and goals?”

It’s happened a number of times now that I have arrived at a company and heard statements like “run projects how you think best. After all, we hired you for your expertise and experience.” These bold proclamations inevitably give way to operational management’s desire to change things for the better good (i.e. over-ride some of my decisions).

Perhaps this happens because project management looks like a logical pre-defined process, much like operational management. However, the whole point of a project is to create something novel and never before seen, thus introducing a large element of the unknown to the undertaking. This is one of the reasons why risk analysis is such a major part of formalized project management methodologies.

Passion or concern can often lead operational management to actions which actually stifle a project. Much like a mother, at some point they have to ‘cut the apron strings’ and allow their child to make some mistakes for themselves.

It’s like watching a child banging their toy against a wall, do you say “that’s going to break if you keep doing that” or do you take the toy and save it from certain annihilation, potentially robbing them of a valuable lesson on taking care of their property? On the other hand, some lessons can’t be learnt the hard way, for example; crossing the road without looking both ways.

The question then becomes, do you stand by and watch someone make a mistake? I would hazard that this would often be the motivation of upper management, that to them it looks like you are about to make a mistake which could cost the company money or damage client relations, so isn’t it logical to intervene before its too late?

I’m fairly sure no managing director wakes up in the morning and thinks to themselves “hmm, how can I make my project manager’s life difficult today?” I should say that I don’t intend for this article to be a denigration of past employers. Operations managers generally don’t acquire their position without being highly intelligent and capable. But I have seen the phenomena Joel Spolsky calls Command and Conquer Management. This is where the person least qualified to make a decision is doing just that.

From the companies I have worked at so far, I have seen three distinct approaches when it comes to operational management dabbling in project management. One type would commonly interject if they felt they had a better way to do things (with changes I could not veto), another would occasionally come to the rescue if things weren’t going as planned (again, with me having no veto power), and probably the most interesting one has been a boss who only occasionally intervened, but still allowed me to have final say.



Personally, I wouldn’t want to work in an environment where people didn’t say something if they felt you were about to make a serious error with your work. But that is obviously part of what team is about. People need to be able to ask questions and give suggestions. But they should also be given the option to reject a suggestion without ego coming into it.

project management isn’t an easy discipline, hence why not everyone does it. As mentioned earlier, the reason for this is because a significant portion of a project is unique. Getting good at tackling the unique aspect of projects only comes with experience, and experience comes in two flavors: success and failure. Unfortunately, it’s hard for some people to accept the unpredictable nature of software development because mistakes can be expensive.

Another interesting ingredient being added to this dynamic is the increasing uptake of industry standard project methodologies such as Britain’s PRINCE2. Although this is definitely a good direction for the software industry, it does pose a potential hurdle.

PRINCE2 is squarely aimed at project managers, there’s no doubt about it. The problem lies in the fact that non-project managers within the team also need to understand the methodology for it to work well. I believe it’s possible for a project manager to teach the basics of PRINCE2 to subordinates such as team managers, programmers, designers, etc. (just enough for them to get by). But would this work upwards, with corporate management?

Needs Analysis for Business Websites

Questions to ask your client before building their website.

This article is most relevant to people who develop standard websites (e.g. a business’ web presence). If your main focus is web-based applications, this paper may have limited appeal.

Client input is the foundation upon which successful web sites are built. It’s absolutely vital that you get your client to articulate their goals in order for you to successfully deliver their project . To help facilitate this process, a number of questions can be asked relating to areas such as target audience, desired look and feel, and what interactive functionality is required.

A good way to tease out your client’s requirements is to use a Needs Analysis document. This is basically a 2-3 page fill in form, full of questions which prompt the client to think about not just the visual elements of their site, but what they are trying to achieve in concrete business terms.

Using a Needs Analysis form provides many benefits. It often acts as the basis for developing a fee proposal or tender (see Writing Fee Proposals). Unless you know what it is your client wants, you wont be able to cost it with any degree of accuracy. Another advantage of a Needs Analysis form is it can present ideas to the client which they hadn’t previously thought of. This isn’t just a boon in terms of up-selling, it also means features aren’t added mid-way or at the end of a project (e.g. client: “I know you’ve finished my website, but can you just quickly add a photo gallery page?”).

The Needs Analysis form I use is broken up into five sections; Company Details, Graphic Design, Business Related, Technical Requirements, and Programmed Features. I will cover some of the questions contained in each section along with the over-all structure of the form.

I always start documents with a short description of what the document is. This is for the benefit of anyone seeing it for the first time (e.g. Document Purpose: this form is used to gather client requirements...).

Company Details – this section is pretty straight-forward, you record information such as the company name, who the main contact is, address, phone numbers, the client’s position within the organisation, etc. It’s also a good idea to note down any other stake-holders that will be involved in the project, and if the primary contact is able to give approval for the work to begin.

The information gathered in the Company Details section will most likely be needed for producing a quote. It will be especially useful if a sales consultant or business development manager is gathering requirements to hand over to a project manager. From this, the project manager will be able to figure out who's who on a project.

Graphic Design – this section is meant to capture details relating to the website’s visual appearance. It is not so much concerned with layout and colour, but rather communication. The information gathered in this section will be most useful to a graphic designer. Good questions to ask the client include; ‘what image are you trying to portray?’ (e.g. friendly, corporate, innovative, etc), ‘what phrase would best describe your website once it’s launched?’ (e.g. ‘these guys look really professional’), ‘what’s the main goal of your website?’ (e.g. sell products online), ‘what else are you trying to achieve with your website?’ (e.g. promote skin cancer awareness amongst young people), ‘what would you like users to do at your website?’ (e.g. register, buy products, etc).

You also want to ask if the client’s logo and branding material is ready. Your graphic designer will want to get his hands on any digital files as soon as possible (e.g. logos, product photographs, etc). Connected to this, you may want to ask the client if they have a style guide. The topic of Flash vs. static HTML also needs to be discussed since there may be SEO and cost implications.

Another important subject is the intended audience of the website. Questions you could ask include; who is your intended audience? what’s their typical occupation?, what is their age range?, is it mostly male or female?, how often do they use the Internet?

You can ask the client to show you some websites they like and have them explain what it is about each site that appeals to them (e.g. client: “I like the clean layout of the site”, “the animated banner is really cool”, etc). If you know that your client likes a particular style of navigation, it makes sense to use that style for their website.

Notice that none of these questions have to do with layout or color schemes (e.g. where the navigation should be, what font should be use, etc). These considerations should be left to the graphic designer, after-all, they are the expert.

Business Related – these questions aren’t directly connected to the visual appearance or functionality of the website, but they may have an impact on the project itself. For instance, you would want to ask questions like: is your content ready?, how are you planning to market your website once it launches?, are you open to developing in stages to manage costs?, do you require an SEO strategy?, are there time constraints (e.g. client: “we need it ready before we go to a trade show in November”, or “we are printing a brochure next month and want to refer to the website”)?

You may wish to ask a few questions about the client’s competitors, such as; do your competitors have websites? what do you like about your competitor’s websites?, what do you dislike about your competitor’s website? Sometimes finding out what someone doesn’t like can be a great help in determining what they do want.

Probably the most significant of the business related questions is about content. Lack of content can be a real killer. A wonderful website may be developed, but if the content isn’t ready, the site is effectively in limbo. One way to help reduce the risk of this happening is to recommend early on that the client engage a content publisher.

Technical Requirements – these questions are mostly system administration related. For instance; you want to find out if the client already has a hosting provider organised. You also need to know if the client has registered their domain name or if they want you to register additional web addresses on their behalf.

Programmed Features – this section covers the interactive elements of the website. Probably the most important goal of this section is to establish the information architecture of the site. This can be done by asking the client what sections their website should have (e.g. press releases, our work, testimonials, etc). The client may also have a need for interactive pages which require custom coding (e.g. sign-up form, news articles, member’s login, photo gallery, etc).

Other significant questions would include; are you planning to sell anything online?, do you require a CMS?, does your site need to work with an existing database?



You’ll generally find that only about 80% of the form’s questions are relevant to any particular project. That being the case, it makes sense to remove or cross-out irrelevant questions before meeting with your client (e.g. you would probably know before-hand if any e-commerce facilities are needed).

Another idea is to pre-fill as much of the form as possible. Besides the obvious benefit of saving time in the face-to-face meeting, it demonstrates you’ve paid attention to verbal requirements which may have already been discussed.

Time Management in a Multi-project Environment

Time and task management in a multiple concurrent project environment.

It’s a major concern that some people believe there is a perfect time management software out there that will fix all their scheduling woes. This challenge can’t be surmounted with technology alone, there are aspects of habit at play here, not to mention the inherently unpredictable nature of software development (e.g. do you know how many bugs your software will have after launch?).

The PRINCE2 manual says that a staff member can only do 3.5 days of productive work in a week (out of 5 days). Other tasks like meetings, answering the phone, attending Janice’s farewell party, and so on take up the remaining time. I have been at a company where management believed staff were capable of 4.5 days of productive work per week; this was pure fantasy, wishing something were true doesn’t make it so. Perhaps this was a misapplication of Parkinson’s Law.

In simple terms, Parkinson’s Law states that people will use up all the time they are given to undertake a task (e.g. it may take 2 hours to stack 1000 magazines, but if you give someone 4 hours to do it, they will take 4 hours). This notion is commonly misinterpreted to mean you get more out of people if you squeeze them, put them ‘under the pump’, give them impossible dead-lines to meet. Sure, this mentality may produce some short term gains, but it is also likely to result in despondency in staff and increased turn-over.

If increased productivity is desired, there are more positive ways this can be achieved (e.g. hiring a casual system administrator instead of using your programmers to do tech support work). I believe Parkinson’s Law can be a useful tool, but only for yourself - it shouldn’t be projected onto other people.



You can schedule programmer time quite nicely using Joel Spolsky’s Painless Software Schedules technique, it’s dragging them off work unexpectedly that’s the killer (see Project Schedules with Google Spreadsheets for an enhanced version of Joel’s approach). I’ve worked at a company where this was common practice (i.e. pulling programmers off work to do other work). The result was a scheduled which had unreliable delivery dates, the schedule still served its purpose as far as task tracking went though.

In an effort to alleviate this problem, I came up with a system loosely based on critical path theory which I called ‘primary/secondary programmer’. An example of how this works would be; you have two programmers on a project. One is known as the primary and has 20 hours of allocated work, the other is called the secondary, he has 10 hours of work. If 5 hours of new work pops up, it’s given to the secondary. The secondary would now be lagging 5 hours behind the primary, but he can still complete his work before the primary does. The project can’t be considered complete until the primary finishes all his work, so you would intentionally give the primary programmer more work then his comrade (e.g. a 65:35 ratio).

There is a company tackling time management with low-tech solutions quite effectively for their particular environment. One thing which they do is have a central ‘time wrangler’, if you wanted a programmer to work on something, you would have to go through the time wrangler to book him. This was done by submitting a resource request via email; just a simple work summary which looked like this:

Client name:           Blue Widgets Inc.
Job name:              Bug fix, ID: 59
Preferred person:      Michael Smith
When it will be ready: 11:00am Tues (26th July)
Due by:                5:00pm Tues (26th July)
Estimated Hours:       1-2 hrs
Priority:              normal

The time wrangler would use this information to insert a new entry into the programmer’s Microsoft Outlook calendar. When the programmer came in to work, they would see they had a few hours of bug fixing to do. Was this a perfect system? Not really, but it was much better then the ‘running around putting out fires’ approach I have seen elsewhere.

Also notice that ‘Job name’ refers to a bug ID, an issue management system is an absolute must for any software development house. The project manager needs to allocate time for bug fixes in smooth spots through-out the week and at appropriate break points (e.g. between milestones). Bugs should initially be assigned directly to the project manager, not to programmers. From there, the project manager decides priorities and re-assigns bugs or minor feature additions, these should be released to programmers in logical batches rather then just opening the flood gates.

The other impressive idea this company came up with was the creation of a position called ‘maintenance programmer’. It was this programmer’s job to undertake bug fixes and changes on old projects.

This was great news for the other programmers because it meant they could start on new projects without worrying about being dragged away at any moment to fix bugs on a project they worked on last year.

Normally, the best person to fix a bug is whoever originally coded it, but after a year, the benefit of this begins to diminish. Realistically, a maintenance programmer is going to have a hard time understanding the business rules of complex software system they weren't involved with, they are more suited to simpler website upkeep.

You will know your project schedule is working well when programmers only come ask you questions every few days, they know what they have to do next and don’t lose momentum. Another indicator will be that your project post-mortems will show very few logged issues relating to missed functionality (i.e. programmers won’t forget to code things).

Often, poor time management isn’t the result of bad scheduling, it’s usually a project management issue. The project manager is responsible for deciding priorities, not the programmers or the operational manager. This is where I have seen real trouble, when upper management assigns priority without understanding the knock on affect on other projects. I believe people worry far too much about delivery dates when they should be more concerned with time wasting resulting from sub-optimal planning practices.

Notes
Be realistic about the availability of resources. Allowance should be made for holidays and time that people will spend on non-project activities. The average working week is only 4 days after allowing for holidays, training, sickness, etc. Of those 4 days, at least another half-day will be spent on other duties, even by dedicated staff − for example, quality reviewing for other projects, line management and meetings.

- Page 181. Managing Successful Projects with PRINCE2 (3rd Ed.)

Wireframes and Mockups - Part I

Lo-Fi techniques for creating effective UI wireframes.

Part 1 focuses on lo-fi approaches such as pen and paper-based techniques. Part 2 is concerned with more refined tools for producing polished UI mockups.

UI mockups, or wireframes, are a major part of any respectable functional specification. A functional specification is a description of how the software will work from the user’s point of view. This article doesn’t cover the reasons why you need a functional specification, for this I would suggest Joel Spolsky’s article Painless Functional Specifications. The focus of this piece is to describe and analyse a few approaches for creating UI mockups.

I’m sure there are many other approaches for creating wireframes, but I can only describe and comment on the ones I have used, making some general statements on what is good (or bad) about them.

Lo-Fi Prototyping – this is just the fancy name for the old butcher’s paper approach. Hands down, its the best technique when a new shrink-wrapped software package is being designed. It really lends itself to collaborative effort, it gets the creative juices flowing, and the speed at which you can produce rough screens is unbeatable.



I once spent four days with a group of developers in a small apartment designing a telecommunications application using this technique. The result was just short of astounding, it allowed us to blast out and iterate ideas very quickly. As the UI designer for the team, I went home at the end of the week with a mass of paper which I turned into over 30 HTML mockups.

This approach is unsuitable for designing simple business websites or software which has been done before (e.g. non-novel systems like a shopping cart). It’s also not so great when a client is directly involved in the project. There are a few reasons for this; it requires a big investment of time on the client’s behalf (they may have a business to run during the day), and secondly; the client-to-supplier relationship often creates a dynamic where they tell you what they want, and you go off and make it. Normally, the client wont hang around whilst you design their software.

Microsoft Excel – yes, as strange as it may sound, MS Excel can be quite handy for producing wireframes, especially for software which is expected to have long vertically scrolling screens. I would never have thought to use it myself, but a company I worked for introduced me to it as their preferred spec’ing tool.



At first I was skeptical, but I quickly warmed to the approach when I saw how fast screens were to make once I got the hang of it. It’s excellent for inserting instructions to programmers (either in comments or as side-bar text). It does however produce exceedingly ugly wireframes; this is a good thing for application design since it keeps everyone’s focus on usability and business logic.

The other great thing about Excel is everyone is familiar with it, including clients. The closest thing I could think of as a criticism of Excel as a wireframe tool is that it produces decidedly uninspiring visuals. I currently don’t use Excel as a wireframe tool, but I would have no problem picking it up again if I felt it was right for a project.

Microsoft Word - another desktop application you wouldn't normally think of as a wireframe tool, Word can be pretty good in certain situations. Generally, the only time I would use Word to represent UI controls is if I am making a ‘mini-spec’ for a web-based application.



A mini-spec is created in one of two situations; as an adjunct to an already ratified functional specification, or as a mechanism for grouping together a bunch of features for a version upgrade. UI controls are represented in a very rudimentary fashion, for instance; (*) would be a radio button, and [x] would be a checkbox, etc.

This works because the interface for the system has already been established (i.e. the system has been coded or a Photoshop mock-up exists). The advantage of this approach is speed; you describe the underlying functionality of the code and only mock-up the controls relevant to the feature rather then drawing the entire screen.

Continue on to part 2 of this article to find out how Visio and Photoshop can be used to produce highly refined mockups.

Wireframes and Mockups - Part II

Techniques for creating polished UI mockups.

Part 2 focuses on tools for producing polished UI mockups. Part 1 is more concerned with lo-fi approaches such as pen and paper-based techniques.

Over the past few years I have been exposed to a number of techniques for preparing mockups. Each approach has its strengths and weaknesses, but generally the best method to use depends on the project at hand. I don’t have a single preferred approach, but choosing the most appropriate style to use at the time can be a tricky undertaking.

HTML mockups – with the advent of tools like Microsoft FrontPage and its successor Web Expression, anyone can make cool looking mockups, to the point where it seemed as though all that was left to do was hand over the HTML to the programmers, and they would take care of the rest.



I’ve used FrontPage to make HTML mockups quite a bit in the past. Some analysts say its a very strong option for designs because it allows you to produce navigable HTML. From my experience, I don’t think its a good choice to use as a first draft system, it can be time consuming and lures you to distraction by unnecessary detail early on (i.e. making the design ‘look pretty’).

The biggest problem with HTML mockups is you have nowhere to put annotations (i.e. generally tech notes directed at programmers describing ‘under the hood’ functionality). As far as navigable mockups go, I’ve never found it to be a big issue with flat mockup structures. Generally people know where pages are going to go to, and in rare cases when a page is going to the wrong place, its nearly always a rudimentary task to direct it elsewhere.

There is one instance when a HTML mockup is appropriate straight away. This is when a complex new screen is being added to an already established interface. The reasons for this are beyond the scope of this article, but suffice it to say that experience has shown that its quicker then first creating a lo-fi version of the UI. One of the other great things about HTML mockups is that they’re easy to distribute to people.

Microsoft Visio – this is the tool I use at the moment for wireframes. It strikes a good balance between flexibility, professionalism, and speed. Visio is great for putting in tech notes without interfering with the wireframe itself, I generally put these in a sidebar to the right.



Visio interfaces come out looking nice and plain, which is what you want. It also has drop-in vector art for all the most common form controls you need (e.g. textboxes, radio buttons, etc).

I find that Visio is well suited for use with clients and their custom web applications. The only fault I can find with Visio is its hard to distribute files, few people have Visio installed on their computers (especially clients), but this is easy to get around, I just print wireframes to PDF.

Photoshop – mainly used by graphic designers to create compelling visual layouts. The beauty of Photoshop is realism. This can be quite exciting since it creates a real buzz on a project, as though things are starting to shift from concept to reality.

Photoshop is best used for creating a single highly polished UI screen. For example, just the home page of a business website, or just the landing page of a web-based application. I have seen graphic designers produce every expected screen of a business website in Photoshop, this is totally unnecessary. The client will get what their website is going to look like from just the home page (i.e. it establishes what the overall look and feel of the website will be).



The obvious short-coming of employing Photoshop is the skill required to use the program, it often takes years just to become proficient with the tool. Iterations can often be slower then other techniques, especially when a complex design with many layers is involved. On the plus side, distribution is a breeze since Photoshop can save image files which anyone can open (e.g. JPEG or PNG).

One of the perils of making wireframes which are seen by a client is the tendency to get distracted by cosmetic factors (e.g. client: “why is everything grey?”, “can we have that button in green?”, “that’s not our logo!”).

Generally what I do before designing anything is tell the client “I’m going to make some very rough mockups of how the screens will look. It wont be pretty, but at the moment we are trying to lock-down where buttons go, the general layout, etc”.

This is where methods like lo-fi prototyping or MS Excel can be helpful, because the screens can’t help but look hideous. The danger with mockups in HTML or Photoshop is that effort can be spent early on ‘making it pretty’. The problem with making things ‘look pretty’ at early stages is time gets wasted when iterative adjustments occur (which they will).

Iterations are the name of the game when designing a system, especially early on. If this is the case then you want to choose the approach which is going to allow you to churn out revisions at super-high speeds.

Creating an e-Strategy

How a website can boost traditional marketing techniques

What is an e-strategy? Good question, I have to admit it is a rather vague notion. One way to describe it is to say that it’s about mixing technology with traditional marketing strategies. As these approaches interconnect, they compliment or magnify each other, thus producing an affect where the whole is greater than the sum of it’s parts.

In more specific terms, an e-strategy is the business strategy applied to an online presence. It generally does not focus on technology comparisons, but rather is geared towards presenting the best possible approach for achieving an organisation’s goals.

Why would a business want to develop an e-strategy? The main reason is because it’s a game plan for how to get the most out of their web presence. The idea is to exploit the Internet and emergent technologies in order to increase revenue or reduce operating costs. A common way of reducing costs would be by automating as many activities as possible. For example; an online book store which does just-in-time printing could send an automatic communiqué directly to the printing company when a book is purchased (the book would then be printed and mailed off to the buyer).

Part of an e-strategy is to make it clear that good technology in itself is not enough, a holistic approach is what is needed. Traditional business techniques also need to be used in order to produce growth and out-do competitors.

As part of this process, a few key questions need to be answered; what role can the Internet play in the business strategy? What is the driving force behind the business? How are customer or target market needs fulfilled? What does the future hold for the business domain and how is change going to be handled?

There are many ways that the Internet can help a business. The examples I have here are by no means an exhaustive list, I’m sure some lateral (creative) thinking would reveal even more options.

Demand Aggregation – as the size of a company’s patronage grows, so to does its ability to secure a good deal for its customers via buying power (e.g. a driving range could buy golf balls in bulk to sell to club members at a better then retail price).

Producer Direct – a business which sells products online can bypass the cost of having a physical store-front. This allows them to pass on savings or ‘perceived value’ to customers (e.g. eBay or Amazon).

Product Re-bundling – having a multitude of customers that grow in an organic manner opens up the potential for related but separate products or services to be offered in combination. This would not normally be possible on a stand-alone basis (e.g. a gym could approach a sports store and strike-up a synergy where-by gym members received discounts on sporting goods).

Customer Self-service – technology can be used to reduce the amount of time staff spend directly interacting with customers for simple tasks or enquiries. A classic example of this is a customer researching a product online rather then phoning a store to ask a shop assistant about the item.

One-to-one Marketing – this strategy emphasises personalising interactions with customers. Having a customer’s full name at the top of an email is a simple implementation of this approach. This increases the likelihood of them actually looking at the email rather then discarding it as junk mail. A more effective usage would be a website where customer demographic information such as age is tracked. This could then be used to target promotional advertising more effectively (e.g. there’s no point showing home loan packages to teenagers).

Channel Integration - this is about having a number of different ways to communicate with your customer or fulfil their needs (e.g. phone, product brochures, direct mail, physical store-fronts, etc). A popular implementation of this approach on websites is to ask a person if they want to receive promotional material via email during a sign-up process.

An e-strategy needs to explain how technology can serve a business’ goals (e.g. to have products on supermarket shelves by the end of the year, to raise skin cancer awareness, etc). This is done by determining how business objectives can be linked to an Internet-based solution such as a website.

Without an e-strategy, technology-based solutions developed reactively may produce short-term benefits, but turn-out to be ineffective and expensive in the long run. For example; if you wanted to develop a mobile-device interface for a social networking website, you could produce BlackBerry and MS Windows Mobile applications, or you could try and capture a far greater audience by targeting just the Symbian OS considering it’s installed on 72% of all smart-phones (Source: www.itwire.com/content/view/14348/127/).

'Maintenance Blocks' - Managing Change Requests

An equitable system for maintaining and upgrading client work after launch.

What Are ‘Maintenance Blocks’? It’s an idea I developed which is meant to provide a fair system for undertaking bug fixes or upgrades on client work. In simple terms; they are pre-paid units of maintenance.

It never felt quite right to round-up 15 minutes of work to one hour (for the purpose of creating an invoice). However, I wasn’t happy about doing work for free for a client just because it was a small task (e.g. creating a new email account, adding Google Analytics to a website, etc).

One of the major advantages of maintenance blocks for clients is that a lower rate is locked-in for future work. There is also a degree of convenience since invoices aren’t being sent out for small pieces of work. In addition, maintenance blocks are very flexible since they can be used for either bug fixes or upgrades to a client’s existing project.

Maintenance blocks are also about mutual obligation. Having a client pre-pay for maintenance work ahead of time is a sign of good faith. In return, I give a guarantee on turn-around time (generally 48 hours from the time the request is acknowledged). If I don’t respond within the agreed amount of time, the client gets their work done for free.

I designed maintenance blocks to be purchased in ‘packs’, generally eight or sixteen blocks, with each block being equivalent to 15 minutes of work. Depending on the complexity of the task (be it an upgrade or bug fix), varying amounts of blocks are consumed. Generally speaking, a minor change would use 1 block, an intermediate change would consume 2-3 blocks, and a major change will use 4 or more blocks (nb. minor or intermediate changes are most common).



I generally have it so blocks do expire, but the amount of time they stay valid is quite long (e.g. 6 months for eight blocks).

The way a client uses maintenance blocks is quite simple. They would email a request for change via email, I then let the client know how many blocks need to be used for the change and how many maintenance blocks they will have left after the change (e.g. “you have 3 maintenance blocks remaining, the change you are requesting will use 2 of those blocks - leaving you with 1 block”). The client then confirms their agreement or raises any questions they may have.

The system is squarely aimed at small bug fixes or changes. For example; “the positioning of the logo on my website looks funny in Google’s new browser, can you fix it?” or “please add a new menu item and page to my website called 'Customer Feedback'.” The system is not meant to cover major changes (e.g. adding online shopping facilities, re-vamping the layout of a website, etc). Generally, if a change is more then 16 blocks in size (i.e. more then 4 hours), I consider it to be beyond the scope of the maintenance blocks system, and therefore would require a separate contract to be negotiated.



Why do maintenance blocks get used for bug fixes you may ask? When a project is still under ‘software warranty’ (typically, for a period of 6 months after completion), blocks don’t get consumed for bug fixes. But after the warranty period has expired, I do charge clients for fixes on their projects even if they are my fault. With the work I do, most bugs are found during the QA cycle, with few emerging past the 6 month point (but it still can happen).

Lastly, I don’t ‘force’ clients to use the maintenance block system if they don’t want to. The alternative is to negotiate a charge-out-rate and turn-around time whenever work needs to be done. At it’s core, the system was created to make everyones' life easier. Costs are settled before-hand, thus allowing us to get on with what’s important; the work.