Top 5 Software Project Management Mistakes

Software projects are hard. Running out of time and budget is the norm, rather than the exception.

How can you prevent your project from ending in disaster?

Here are the top 5 mistakes you should avoid:

1. Following the Waterfall model

The Waterfall development model has long been considered fundamentally flawed for software development. It works for engineering projects in the physical world, but software development is very different from building a house.

Using the Waterfall model assumes that you know absolutely everything about the final system, before you even start.

Software is a living, ever-changing organism that grows and responds to changing needs and specifications.

A much better model is iterative development. This breaks the lifecycle of software down into many "mini-waterfall" phases that help you respond effectively to ongoing changes.

2. Insufficient upfront planning

In contrast, following an iterative process can sometimes lead to lack of sufficient upfront planning. It is tempting to start writing code on day one, before the problem is fully understood.

Instead, earlier iterative phases should focus on creating high-level documents explaining the "big picture" and major problems the software aims to solve. Depending on the complexity of the software, it doesn't need to be a full functional specification. It should simply have enough information to make sure everyone on the team understands what the software is supposed to do.

Next, it helps to rough out layout and interface details using mockups or wireframes.

Finally, before full implementation, it pays to build a "working prototype" that contains most of the user interface, but perhaps not all of the backend. This allows users to try things out and make suggestions when the cost of change is low.

3. Overly optimistic estimates

Programmers are notoriously optimistic when it comes to estimating how long programming tasks will take.

I blame this primarily on the "Programmer Optimism Curve" (POC) that I describe in the popular "You are not 90% done" article. This results from the actual scope being larger (often 4-8X) than originally expected.

I recommend being prudent and following these 5 steps to estimate software development time.

4. Adding too many people

Ever since the dawn of software development, managers have assumed that building software is just like building things in the physical world.

Nothing could be further from the truth.

In 1975, a brilliant computer scientist named Fred Brooks wrote a book called "The Mythical Man Month".

One of his many observations was that for a complex process like software development, you should keep your team as small as possible to reduce the total number of communication channels.

In fact, "Brook's Law" states that "adding manpower to a late software project makes it later," followed by the cheeky "Nine women can't make a baby in one month."

This holds true now just as much as it did when he wrote about it in the mid-70s.

5. Incorrect use of todo lists

Projects to-do lists often end up as a brain dump of specifications, questions to be answered, unapproved features, and miscellaneous chores that need to be done.

As I summarized in my personal blog, the best practices to make a to-do list work are:

• Using verbs
• Being specific
• Grouping by context
• Focusing on next

For a detailed account of why most todo lists don't work, and how to manage them better, be sure to read David Allen's "Getting Things Done" (GTD).

Summary and recommendations

In conclusion, to avoid making these common mistakes:

1. Use an Iterative development model, not Waterfall
2. Do enough upfront planning
3. Make realistic time estimates
4. Keep your team small
5. Use the GTD methodology for todo lists

Following these guidelines will give your project the best chance of success.

---

About the author: Jason Hanley has been developing commercial software since high school, and is the founder of PMRobot.com.

5 ways to lose your job by "going agile"

 Yes, this is written from personal experience. With previous employer, I went to bat for the benefits of Agile project management. Though leaving was not a direct result of that effort, the relationship capital that I spent had a huge impact on my ability to add value. Eventually, I was clearly unhappy, they were clearly unhappy and we fairly amicably went our separate ways.

That said, the remainder of this post won't be written it in the first person. Doing so would  introduce too much of my own biases. Also, some of these points are slightly exaggerated from the actual occurrence so don't assume I'm as dumb as all that. 

I hope is that these hard-won lessons can be helpful to you in creating the change you want to see in your organization.  Regardless of  who you are or where you work, either as a project manager or team member;  in a large enterprise or a small consulting shop, in digital marketing or software development, I bet there's at least one pitfall I can help you avoid.

1. Complain about the current system

If you’re laboring under something like waterfall, or  a basic lack of project management processes, you can probably see that the grass is greener on the Agile side. If you're really antsy about it, you’ve probably read tons of great material at mountaingoatsoftware.com or maybe agilemarketing.net, and you know that things could be better.

Awesome, you are almost undeniably correct. But so what?

Bitching and moaning about the status quo is not a good way to create organizational change. Instead it’s a great way to create a rift within your team. Some of these people were involved in creating the current processes, conscious or not. Beating up on the these process doesn't make you look smarter than everyone else, it makes you look like you think you're smarter than everyone else.

Negativity begets pessimism. If you focus on what’s not working about your current project management processes, the natural tendency is to look for the downsides of any alternatives as well. Instead, paint a picture of the possibilities that you see for your team going agile.

2. Be stealthy

So, you’re using positivity to draw a compelling vision to get people on your side. Unless you’re an exceptional salesperson, you’re almost certain to get some push back. It can be frustrating. You might be tempted to just put up a taskboard in your office one day, in the hope that the value of making work visible will be immediately appreciated.

That can even work to some extent, it is really cool to actually see all the work in progress and in the backlog. But simply putting up a task board does not an agile team make. Assuming that everyone will follow your lead into agile is actually a very un-agile way of operating.

You’ve drunk the kool-aid and you know things can be better. Unfortunately, the truth is that things won’t get better if you don’t have proper buy in from the rest of your team. Take the time to have the conversations required to secure this buy-in, both above and below you. 

3. Get hung up on the software

When you’re at your most enthusiastic about the potential of transitioning to agile, it’s easy to get caught up in the fun of checking out all the different software tools out there. It is important, but it can be a distraction from the real issues.

A focus on software can easily devolve into a debate between the current “waterfall-y tool” and whichever shiny new “agile tool” you’ve got your eyes on. That’s not where you want the focus of your discussion. It should be about the processes used and cultural practices needed around those processes.

4. Drop balls

There’s nothing like an angry client or executive to put a damper on your efforts to create change. Never mind that things probably weren’t going all that smoothly in the first place; rational or not status quo bias makes it very likely that the blame will be laid at least partially on the transition to agile.

If you’re championing the transition, then you’re placing some of your own credibility on the line. Be aware of this, and be willing to put in the extra time and effort to protect your credibility by staying on top of information and deliverables.

5. Do it in a culture of fear

Take a look at your organization, and your own motivations for wanting to go agile. Maybe the agile manifesto speaks deeply to the kind of environment you’d like to work in. That may not be the case for the people around you. There’s a certain kind of safety in having a silo between you, and the developer two desks over.

Creating an agile culture requires that people step up and take responsibility for the quality of each deliverable (or story) at each stage of the process. Face it, your coworkers might not be cut out for agile.

If this describes your situation, it’s not worth the emotional energy required to fundamentally change the culture. Or more eloquently put:

Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.

-Warren Buffett

Be open to the idea that Agile will never be a fit for your organization... then polish up your resume.

Doing it right

Having gone in depth about what not to do, here's a very quick list of how it should be done.

• Be humble
• Talk to people one on one about your vision, and what you see in it for them
• Get outside help
• Get training
• Be honest about the pros and cons
• Be patient, now might not be the time for your organization

Also, make sure to do your research, so you know what you're talking about. Here are some good starting points:

Agile Software

agilemanifesto.org
http://www.agilealliance.org/
mountaingoatsoftware.com

Agile Marketing

agilemarketingmanifesto.org

http://agilemarketing.net/

What do you think? Have you had similar experience or difficulty transitioning an organization to Agile practices? Any insights to share about how it should be done? Let us know in the comments.

-

- John Mardlin

A Guide to Effectively Managing Your Solo Software Project

This article will help you create some very basic systems for managing your solo software project. It won’t help you decide what projects are good ideas, or successfully market your software, but following its advice will make you more likely to get to a finished product, instead of giving up in despair.

 

Who will find this helpful?

• a hobbyist or pro using their spare time to build something they want
• an entrepreneur building a minimum viable product for a business idea
• a freelancer building a web or mobile app for a client
• anyone who wants to learn by doing

I’m sure many people are already on board with the need for some systems to help guide the creation of their software, but I can literally hear some of your bloodshot underslept eye-balls rolling in their sockets and saying “processes and project management systems are for the office, this is just overhead that gets in the way of getting stuff done".

I beg to differ.

Why you need a system

Even a simple project has multiple moving parts. It may be that you’re capable of keeping track of them all, but that requires effort and costs you brain power, your most precious resource for software development. The reason for this is known as the Zeigarnik Effect:

The Zeigarnik Effect is the tendency to experience intrusive thoughts about an objective that was once pursued and left incomplete (Baumeister & Bushman, 2008, pg. 122). The automatic system signals the conscious mind, which may be focused on new goals, that a previous activity was left incomplete. It seems to be human nature to finish what we start and, if it is not finished, we experience dissonance.

The take home is, unfinished tasks will trouble your worried mind.  Storing your tasks somewhere trusted and finishing them as fast (or faster) than you start them, will free your mind for coding.  A simple system will serve this purpose, while introducing minimal extra effort.

1. Getting Started

It may seem obvious to you what your project is; but until you’ve written it down, and explained it to a few people, you can’t be sure that it’s well defined. Figuring out why you’re doing this project and what your goals are doesn’t take long, and will pay dividends down the road.

Create a one-page project charter to outline the scope, objectives and people involved with your project.  Your charter should answer the following questions:

What are your goals?

Get high level, ask yourself WHY you’re doing this, and what success looks like. If it’s a freelance project, establish this with your client.  If it’s a side project, by straight up about it. Are you developing a minimum viable product to test a business idea or is it just something you think would be cool to see or make your life easier.

Who are the stakeholders?

Whose input is important to guide your project to success? Maybe it’s just you, maybe it’s potential customers or a client.  How will you communicate with these people? How much influence will they have?

What will the product enable you to do?

This is akin to an epic user story for your product. Don’t talk about how the product will do what you want,  focus on what you want.

A basic user story format is:  "As a <role>, I want <goal/desire> so that <benefit>". This keeps the focus on solving the problem and avoiding tunnel vision around specific features for solving the problem.  For example the epic user story for your product might be “As a bowler, I want to know how what I eat for breakfast correlates with my bowling score, so that I can always eat the right pre-bowling breakfast”

How much time are you willing to spend on this?

Particularly if this is a side project, it will almost inevitably take longer than you think. At the outset, we tend to see the work breakdown at very low resolution. Once you’re face to face with a particular task, you see the fine details and nuances much more closely. In one of the most popular quora answers ever, Michael Wolfe deals with the reasons for this very astutely.

When it’s no longer fun and exciting, will you keep plugging away, or will you accept the sunk costs and move on? Decide beforehand how far down the rabbit hole you’re willing to go.

2. Doing it and Managing it

Planning

Since you’ve already created a scope now you just have to break it down into manageable tasks, ideally things which aren’t much more than what you can do in a given evening or two worth of project time.  Keeping your tasks small will help you to see your progress and feel great when you check something off.   

Tasks that are further down the road, will inevitably be more ambiguous; no problem, as they come closer to being executed on, you can split them up further.

Write each of these tasks on a sticky note, we’re going to use them to fill up your personal kanban board.

Tools

The Kanban Board

Find a visible place in your workspace and put up a whiteboard. Keep your kanban board really simple with three columns: Backlog, Doing and Done.

There are two simple rules for using personal kanban:

1. Keep your work somewhere easy to see
2. Limit your work in progress. Typically no more than 5 tasks at a time in the “Doing” column.   

Both of these rules would make Zeigarnik happy; they ease the burden of how much you have to store in your limited grey matter and put it somewhere you can trust you’ll see it.

Even when there is extra space in your “Doing” column, have a bias towards finishing a task over starting a new one.  Only introduce new tasks into “Doing”, if everything else is stalled, and there’s absolutely nothing you can do to move it forward.  

If you’re waiting on a domain transfer, go ahead and start working on wireframing. Don’t create a separate column for stalled or waiting items, even if you’re not working on it right now, it’s occupying precious brain cycles.

Time Tracking

No one likes tracking their time, and most time tracking software makes the process even less fun, but if you keep it simple, it can help to give you very valuable data and improve your sense of how long a task really can take.

Use your personal kanban to track when you moved a task into “Doing”, when you moved it into “Done”, and how many hours you spent on it.  You can do this just by writing it on your stickies like so:

Setting up these tools adds minimal extra time to the initiation of the project, and will pay huge benefits by releasing your mind from having to track all these items and allow you to focus on the execution.

Wireframing

I do believe that wireframing and mapping out the workflow of your product are very much worth your time. We use Moqups, which is really user friendly and takes no time to figure out.

Version Control

Even though it’s just you, using version control will help you to undo your mistakes and create an easily trackable history of your progress.

Git Immersion is a great tutorial for setting up a git system. If you want a cloud based repository, with pretty graphics illustrating your branches and merges, Bitbucket’s free plan should be totally adequate for you.

Execution

Here’s the fun part, I hope that creating the charter and setting up your tools only got you more excited about the awesome code you’re going to write.  

This is your project, it’s not my place to tell you which languages, frameworks and other technologies to use, you know what works for you. Unless this is a project intended to help you learn some new technologies and frameworks, you probably just want to get going with the least amount of new learning required.

Scope creep is the great enemy of getting things done. If your imagination, your client or other stakeholders are introducing new and wonderful features to distract you, nip that in the bud.  This is why you created your project charter. Keep it beside your Kanban board, where you can see it and remember what you’d first set out to do. If the project drifts from the charter, make sure there’s good reason for it.

Keep moving, do what you can to make some progress every day to stay motivated.  

3. Releasing 1.0 and/or Closing

Maybe you release your 1.0 and this project blow up into a huge success and becomes your life’s work.  Or perhaps you’ve met the goals of your original charter, but you see potential to go further.

On the other hand, maybe you’re completely done with this piece of software;  it’s served its purpose of satisfying a client, or teaching you what you set out to learn, or is now serving you as a handy little tool.

Either way, upon completing the first version of your project, it’s worth doing some work to close it out.  The scale of this effort really depends on the project.

At a minimum, you should archive your post it notes somewhere safe.  When starting your next project, they’ll be useful for remembering what tasks and time commitments were required last time.

Now sit down, have a beer, and contemplate how awesome your shiny software is.

From D.A.K Photography

References and inspiration:

https://news.ycombinator.com/item?id=4910022

http://pm.stackexchange.com/questions/195/minimum-project-management-practices-for-one-man-software-projects

http://stackoverflow.com/questions/1523418/single-person-application-development

http://kiragiannis.com/business/10-tips-to-guarantee-success-on-solo-projects/

- John Mardlin

Too much going on? No problem, you can sort it out.

Now it's easier to get your priorities in order

We're always working to make what's already a great project management app even better and more user friendly.

Now you can spend less time managing and more time getting things done.

Drag and drop your tickets anywhere in the queue

You no longer have to click arrows to move the ticket from one column to the next. The updated sorting saves time, and makes it much easier to get everything laid out in just the right way.  If you haven't seen it, take a look: https://pmrobot.com/tickets/sort

About PM Robot

PMRobot keeps everything in one place, making your job easier.

No more information scattered across 7 different tools.

With PMRobot, there's only one tool to learn, and one place to search for all your files, tasks, and project information.

Questions or ideas? Contact us at http://feedback.pmrobot.com/

---

- John Mardlin

Perils Of Multitasking infographic

As a follow-up to my productivity post entitled "Multitasking is toxic", Peter Kim emailed me a great infographic with some stats about how bad multitasking really is for you.

Have a look:

The original can be found here.

How to: Manage Remote Projects

Managing a remote project is hard work!

Before starting Syllogistic Software, I worked for a large software corporation, and managed several remote teams. It was always a challenge to:

1. Stay on top of remote workers' task status
2. Communicate questions and answers
3. Help the remote workers keep up with everything else happening in the project

So what tools did I employ to help the situation?

1. Email
2. Conference calls
3. Microsoft Project

When I started my own software consulting company, I tried using these same tools, but found a few problems:

Problem 1: People don't answer email

Even back then, people were buried in email. They choose the easiest ones to answer and ignored the rest.

If you asked them a complicated question about the next steps of a project, it sat in their inbox for days, gradually pushed down the list by other incoming emails.

Problem 2: People forget what is said in meetings

To solve problem 1, I would often call or schedule a meeting. During the meeting, we would go over the questions, determine action items, and record them in meeting minutes.

Unfortunately, some of these actions items would sometimes still fall through the cracks, and not make it to a remote worker's todo list.

Problem 3: Microsoft Project only works for initial high-level planning

MS Project is a great tool for coming up with a "grand" plan before starting a project. But the pretty Gantt chart you create is only valid for a day or two before -- you guessed it -- something changes.

Then you have to go back and re-adjust everything, and your beautiful chart starts looking messy. A week later, there are 5 new scope items, and you're already well behind the planned schedule. Your project plan has essentially fallen to pieces, because you've been so busy putting out fires that you haven't had time to keep it current.

So how do we solve these problems?

After many years of iterating through various fixes, I came up with several techniques that worked:

Solution 1: Clarification questions

The very first version of PMRobot came with a feature called "Ask a clarification question." This remains one of the most important innovations.

When you ask someone a question, it tracks its status, and helps remind the person who has been asked the question. This way, they don't delay the entire project by forgetting to answer.

Solution 2: Track work items in one place

Instead of requiring people to keep track of everything they need to do on their own, create a central work repository that's easy to keep up-to-date.

PMRobot provides a dashboard for workers that shows them exactly what needs to be done, in the exact order they need to do it. After a quick glance, they know their next step.

In addition, if they ask a question about a particular feature, the answer isn't lost in some document called "Week 5 Meeting Minutes." The answer to their question is in the exact same place as all of the other work details.

Solution 3: Use a dynamic project management tool

Microsoft Project is great for static, high-level, upfront planning. If you need a rough overview of the "grand plan," it can help.

Once the project starts, however, you need a dynamic tool that makes it easy to add and update new information.

A major part of project management is change management. Clients change their minds, technology fails, people get sick, and generally -- things change.

Your project management tool needs to be built with change in mind.

PMRobot is built with change management at its core. Every feature helps you control the chaos, and manage each change one by one, getting you closer to meeting your project goals.

Summary

As you can see, many of the features built into PMRobot have been designed to solve very specific problems -- problems that are very common to software consulting.

If you're struggling to keep up with emails and conference calls, consider trying a new approach, and see how these techniques can help tame your chaotic project.

---

About the author: Jason Hanley loves bringing order to chaos. He travels around the world, manages a team of remote developers, and is constantly iterating and improving PMRobot.com.

- Jason Hanley

Top 3 Worst Ways to Manage a Team

Five years ago, I wrote a short post about the worst possible ways to manage people. These are still popular techniques that managers often fall back to.

So what are these common management traps you should avoid?

#3 - The Ostrich Mentality

People fighting? Project running eight weeks behind schedule? New technical challenges are making success look unfeasible?

No problem! Carry on, business as usual. No need for change. Let's just keep doing things the way we've always done them.

This is what I call the Ostrich Mentality. Just stick your head in the sand and hope everything turns out alright.

What do to instead?

Admit problems frankly, have a discussion, and take action to change things.

Not tomorrow, but today!

#2 - The Ditch Digging Theory

This is when a manager believes that every task in a complex business process is equivalent to simple manual labor.

When a project is running behind schedule, they simply add more people.

This concept works fine -- if you are indeed digging a ditch. If you're doing anything more complicated, it fails miserably.

Adding more people to a project that is already late can actually make it take longer! I discussed the details in my post about keeping your teams small.

What to do instead?

Realize that business and information technology projects are complex beasts, involving specialized knowledge, and lots of communication.

If a project is running late, resist the urge to add more people to speed it up.

Instead, focus on trimming the scope to the bare essentials, and getting a solid deliverable out there. Then, create a follow-up project for the remaining lower priority pieces.

#1 - The Warm Body Theory

This one bothers me personally the most, probably because it is so prevalent and so toxic.

When managers have "warm bodies" (ie. people sitting in an office or meeting room) in their field of view, they equate this to productivity.

Nothing could be further from the truth.

If your employees are physically present at the office 10-12 hours a day, how many of those hours do you think they are mentally present, and actively contributing to the project?

Pulling five people into a two-hour meeting to "discuss the schedule" might burn $1,000-$2,000 of budget, and accomplish next to nothing.

What to do instead?

Make the schedule (the real schedule) and task commitments public and accountable.

Track everything in a live, accurate system that the manager, workers, and clients can access and update in real time.

Embrace flexible working hours and telecommuting. Let people balance their work and life commitments.

Once you've clearly defined what needs to be done, and who is responsible for doing it, you won't need to chase people down every five minutes for a status update!

Summary

To briefly summarize, here are the top 3 management "techniques" to avoid, and how:

• The Ostrich Mentality: Keep your head above the sand and take action!
• The Ditch Digging Theory: Don't add more people to a late project!
• The Warm Body Theory: Track accountability, and let people take responsibility!

---

About the author: Jason M. Hanley has owned a software consulting company for 9 years, and is the founder of PMRobot.

New Feature: Two-step verification

The standard ticket workflow in PMRobot is very simple. For instance, if someone finds a problem:

1. A bug ticket is submitted and assigned
2. The bug is fixed and marked 'resolved'
3. The ticket is returned to the original submitter to be verified

There are cases, however, when you need an extra level of verification.

For instance, if it's a very complicated problem that requires a lot of testing, you may want a member of your Quality Assurance team to check the resolution first.

As of this week's release, PMRobot now supports this workflow in two ways:

1. A project can have a "default verifier" who will be required to verify tickets first, before they are returned to the original submitter
2. Individual tickets can set the "verifier" field to require two-step verification for just that ticket

The new workflow looks like this:

This new workflow is very powerful, but completely optional. If you don't set a verifier, everything will work exactly as it always has.

If you'd like to learn more, check out the full tutorial at:
  http://help.pmrobot.com/2012/tutorials/two-step-verification/

And if you have questions, don't hesitate to contact us here.

New Video: PMRobot tour

We've updated our product tour video at https://pmrobot.com/tour

The new tour features a fictitious software consulting company working for "Fun Pet Games Inc." to create the new hit app "Angry Hamsters".

We show you how quick and easy it is to:

• Create and assign tickets
• Ask and answer clarification questions
• Log and track time and use automatic timers

Check it out at http://youtu.be/4Oy4-P9ZRF8 or below:

You are not 90% done

Have you ever had a programmer tell you that they're 90% done?

It happens all the time. Don't believe them.

I'm a programmer. I should know.

You see, there's a funny thing with software. It's very fluid, and can end up being very complicated.

For simple tasks, it's fairly easy to estimate the effort required, based on previous experience.

An example often used in project management literature is "digging a ditch".

If an average man can dig a 10 meter long ditch in 1 hour, then some excellently simple math can tell you that:

• That same man can dig a 20 meter ditch in 2 hours
• 30 men can dig a 300 meter ditch in 1 hour
• 500 men can dig 50 100 meter ditches in 1 hour

Unfortunately there are a lot of people that still try to apply this same logic to software development.

It simply doesn't work. Here's why. Let me tell you a little story.

Mark the Manager gives Peter the Programmer a specification for a new, complex feature in an existing, complicated piece of software.

Mark asks for an estimate, to which Peter replies, "Well, there are a lot of unknowns, but based on the spec, I think 2-3 weeks. Worst case scenario? 4 weeks."

Mark would like it done faster, but agrees to the estimated timeline and gives the green light.

Peter starts working steadily, 40 hours a week, with no vacation, personal, or sick time.

Here are his progress reports:

• Week 1: 35% complete -- Perfectly on schedule
• Week 2: 65% complete -- A bit behind, but still on track
• Week 3: 85% complete -- Uh oh, but at least we'll have it next week
• Week 4: 90% complete -- Ok, now we're late
• Week 5: 95% complete -- Customers are getting anxious
• Week 6: 97% complete -- Customers are irate
• Week 7: 99% complete -- Customers are leaving
• Week 8: 100% complete -- We are bankrupt

Disaster! What went so terribly wrong?

Perhaps the following visualization will help:

This is such a common curve in software development, it should have a name. If it doesn't already, I propose calling it the "Programmer Optimism Curve" or POC.

So what do we do to prevent this from happening? There is clearly no silver bullet solution.

I've written about my 5-step software development estimation method. That can certainly help.

The "story point" methodology from Agile can also work well when you have a long project with the same team members.

Jeff Atwood has some good suggestions about listing todo items too.

Of course, "knowing is half the battle," so now that you're aware of the problem, you can start taking active steps to keep it from sinking your ship.

- Jason Hanley

Eating your own dog food

There's an odd term in the software industry called "eating your own dog food."

Microsoft coined this term in the late 80s.

The main idea is that companies that make a product should use that product on a daily basis. That way, you can experience the pleasure (or pain) yourself, and have a better idea of where to focus resources.

At PMRobot, we use our own software every day.

It was conceived and born in our sister company, Syllogistic Software, and continues a core element of our processes.

"Dogfooding," as its often referred to, is absolutely essential when building a product, because it really helps motivate internal innovation, and quick fixes to problems.

A similar example, dating all the way back to 1981, is when Apple decreed in a memo:

“EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers.” - An Apple On Every Desk

If an annoying change makes it to the server, we experience the pain first hand, instead of just hearing a second hand account from our customers.

If you develop a product, consider making daily use of that product a habit.

I guarantee it will help you produce something of much higher quality.

You can't assign 1 task to 2 people

This is one of my biggest pet peeves with certain project management software packages out there.

You cannot assign one task to more than one person!

And yet there is tons of project management software out there that lets people adopt this bad practice. Have you ever tried asking a group a question? It just leads to individuals assuming that someone else will take care of it.

You: "Hey team, Is the release going to be ready for Friday?"

Developer: "Well, I've done everything I can, but the client hasn't sent their logo yet."

QA Person: "The file interface is still buggy, but I'm not sure if I'm supposed to log bugs about that yet."

What's wrong here? There's no clear responsibility and no one owns the task.

Responsibility is key to all projects, and every task needs one person to be ultimately responsible for moving it forward.

This does not mean that multiple people can't collaborate and contribute towards the solution, but multiple assignment is often very dangerous.

Instead of both people taking responsibility, each one assumes the other one has it covered, and nobody takes any action.

This is why in most companies, there is a single CFO who is ultimately responsible for the finances or a COO who takes ownership of sales and operations. They would not be able to succeed without support from their teams and colleagues, but at the end of the day, they are responsible.

From the very beginnings of PMRobot, when it was just a simple ticketing system, we designed it to ensure that a ticket could only be assigned to one person at any given time.

This leaves no chance for ambiguity or misunderstanding about who needs to get what done.

If you want to increase your efficiency and reduce the number of things falling through the cracks, make sure you only assign things to one person.

Forget Flagging Emails - Follow Up Then

I've recently been introduced to a great tool that's helped me in managing projects and fits perfectly into my personal workflow of how I deal with emails and keep on top of things where I need to make sure some action gets taken.

In the past, I flagged emails. First in Outlook and then a few years later using "Stars" in Gmail. It works pretty well. After I sent an email, if I wanted to make sure that the person that I sent the email to actually did something with it, I would go into my sent items folder and Star the email. Once a week or so, I would cycle through my Starred items and see if there were any messages I needed to follow up on…

Enter Followupthen.com. Before I go on. I don't know the people who developed this product and I have no affiliation with them other than being a big fan of their service!

Basically, you can send an email to 1week@followupthen.com, 3hours@followupthen.com, nextmonth@followupthen.com or any other description of time you can think of. After that set amount of time, you'll get a reply/forward from Followupthen (with the same subject line so that message threading works correctly) which basically brings that conversation right back into your inbox.

There's a few reasons I like this. But before that, I'll illustrate the two different ways that I use this service.

If I'm sending an email and I want to basically remind myself to follow up a week later (if I don't hear back from the recipient) it's as easy as BCCing 1week@followupthen.com. No extra action is required. I don't need to look up the email after sending it and mark it. The recipient has no idea about it and I can feel confident that if I don't hear back in a week, that email conversation will magically pop back into my inbox for me to follow up on.

The other way I've used the service is when I receive an email that I don't necessarily want to write back to immediately. Whether it's a good practice or not, I'm a big fan of a clean inbox. So when I get those emails, if I want to remind myself to reply 2 days later, I simply forward it to 2days@followupthen.com and then archive it. Again, it fits right into my workflow, which is what makes the service so useful.

The one downside or questionable part of this is that I am sending some of my emails to this service. I'm careful that nothing with even the mildest amount of confidentiality goes out this way. That being said, considering that Google and Apple basically own most of my information anyway, it's probably not too big of a deal.

Finally, aside from actually using the service, it's also been a good learning for me in terms of creating meaningful business solutions. The service is simple. It does one thing. And it does that thing well. The most important part for me is that it fits into my workflow and as a result, it was really quick to adapt to.

We are taking this lesson into account as we continue to improve PMRobot and looking closely at the workflow of project managers and software developers to ensure that PMRobot slips right into the way most people are working already! Have feedback about how we can improve PMRobot from a workflow point of view? Drop me a line at ramy@pmrobot.com.

Multitasking is toxic

Everybody multitasks. But should we?

People consistently overestimate their multitasking ability.

There is huge power and efficiency to be gained by batching similar tasks, or "single-tasking" as I like to call it.

Email, social networking, and especially chat programs are notorious for breaking focus and concentration.

I discovered what a difference this makes when I was running my company from New Zealand and all my clients and employees were in North America.

There was a more than a 12-hour time difference, so I was essentially forced to track and batch all my tasks using an early version of PMRobot.

When I got up in the morning, the day had already ended in North America, and I was able to get work done with zero interruptions.

This resulted in a huge productivity boost!

As I'm writing this blog post, I have a number of tabs open for related material, but I've closed Gmail, Twitter, Facebook, and anything that could interrupt my flow.

I do the same thing when I'm programming. Before I open Eclipse to write code, I close everything else that's not related.

What time is it where you are right now? What major goals have you accomplished today? How many interruptions have you had?

Trust me, give single-tasking a try! I guarantee you'll be more productive.

Keep it simple: Ticket workflow

A lot of tracking systems have very complex ticket workflows.

These are often designed to prevent mistakes, but I've found that they often add too many steps to the process, which people eventually ignore.

With PMRobot, we decided to go a different direction, and limit ticket states to:

1. Open - There is work remaining
2. Resolved - The person who did the work believes it is completed
3. Closed - The person who submitted the ticket confirms it is completed
4. Blocked - Work cannot continue due to an external factor (used sparingly)

There are a few common states we decided to leave out since we didn't feel they added sufficient value. Here's why:

New: This is an an open, unassigned ticket. Why add an extra step?

Accepted: This isn't much different than an open, assigned ticket. Again, we don't see a lot of value in adding this extra step.

In progress: This is a useful state to have, but often isn't used correctly. People often mark ticket in progress and then forget about them. Instead, we tend to use time logs and auto-scrum to track what is currently being worked on.

Reopened: This doesn't seem to add much value over the 'open' state. We track and display the number of times a ticket has been reopened, but don't feel it requires a separate state.

What about your process? Do you use states I haven't listed here? Tell us about your experience with ticket workflow.