Showing posts with label estimation. Show all posts
Showing posts with label estimation. Show all posts

Friday, May 31, 2013

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: has been developing commercial software since high school, and is the founder of PMRobot.com.

Wednesday, May 1, 2013

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:





-

Monday, February 4, 2013

6 way to make your clients love you while staying sane

You work hard to get your clients. All those calls, conferences and coffee meetings aren’t just for fun. So you’d better take care of them once you have them. It may seem burdensome at times, but the effort invested in strong relationships and doing great work will pay back in growth opportunities.

In their book “Leading on the Edge of Chaos”, Emmet C. Murphy and Mark A. Murphy state that a 2% increase in customer retention has the same effect as decreasing costs by 10% . Making clients happy is one of the best ways to grow a business. They'll spread the word for you so you can spend less time selling, and more time doing great work.

Build your business on these 6 pillars to keep your clients and grow your business:

1. Make honest and realistic estimations of timelines

We all do it, and it happens in every industry. At the start of a project, you’re feeling good and you know the finished product is going to be great. You’ve made a list of everything involved, and you’ve guesstimated how long each piece will take. This is where things get dangerous. We can be tempted to over-promise when entering into a new relationship, but over-promising does not create sustainable relationships. Set realistic expectations for your timelines, and give yourself some padding for bumps in the road. Because even when you think you’re almost done, you’re probably not.

2. Be a great communicator

Find out your client’s preferred method of communication and use it. If they leave you a message, don’t email, call them back. Make sure your clients know what's going on, before they start to wonder about what you’re up to by providing them with regular updates on a schedule that makes sense for the project. Be especially conscious with formal reports; make your reports concise and understandable, use agreed upon metrics for success, and use visuals when possible.

3. Be Respectful

Your client may not have the same level of expertise that you do (that’s why they’re paying you), but they’re smart enough to know they need you. Take the time to educate them in how you work and what processes you use. Steer clear of jargon; cut down on the three letter acronyms that you throw around casually with your colleagues. Instead, pay attention to how your client speaks, and build that language into your conversations with them.

4. Agree on what success looks like

Doing work that makes your client happy requires great empathy. From the beginning, you need to understand their needs, and get a clear picture of what you're working towards. Once you think you know what you're building, tell your client what you'll be doing. Agree on what needs to be delivered, and how that will be measured. It takes more work upfront, but getting everyone on the same page creates a lot of trust. This trust enables you to do the work, without being constantly pestered. The extra effort at the beginning makes you far more likely to deliver a great product.

5. Set boundaries

You want to keep your clients happy -- that’s why you’re reading this article. You want to reach new heights, diveak down walls and meet stretch goals for them. But remember, they’re looking to you not just to do some work, but also for leadership and guidance. This means letting them know when their ideas won’t work, and not giving in to every demand. If they insist on a change, let them know, in writing, how their request differs from the original scope, and how you expect it will impact the project.

6. Do great work

Obviously! Of course you do great work, you always put your best into every project and sweat the details, right? Great, but not everyone does, and time saved by cutting corners could end up costing you many times over in rework and damaged relationships. By all means, extend yourself, take on big projects and grow, but be sure that you're willing to do what it takes to delight your clients with the finished result.

We can take another great statistic from Murphy and Murphy’s book “Leading on the Edge of Chaos”: organizations that prioritize the customer experience generate 60% higher profits than their competitors. With the rise of social media, people increasingly rely on word of mouth and reviews to make buying decisions. It becomes a virtuous cycle: This means doing great work and making clients happy can be an excellent marketing strategy, which means you can spend less time selling, and more time doing great work.

Sunday, February 12, 2012

The history of issue tracking systems

Web-based issue tracking systems (often referred to as "bug tracking" systems) have been around for a long time. Let's take a trip down memory lane and review issue tracking software to date.

1998 - Bugzilla

Bugzilla is arguably the great-grandfather of all web-based bug tracking systems. Written in Perl in 1998, and still in active use today, it defined a lot of conventions used by the systems that followed.

A bug in the basic Bugzilla workflow can be in one of the following states:
  1. Unconfirmed
  2. New
  3. Assigned
  4. Resolved
  5. Reopened
  6. Verified
  7. Closed
Bugs can transition between these states in a number of standard ways. For example, when a developer completes work on a bug, it moves from Assigned to Resolved. A quality assurance (QA) person then tests and can put the bug into the Verified state if the developer's fix is confirmed.

This workflow has remained largely unchanged over the years.

In addition to bugs, Bugzilla allows "tickets" to track and prioritize feature requests in the same database.

2000 - Mantis Bug Tracker

Started in 2000, but not reaching version 1.0 until 2006, Mantis Bug Tracker (or "MantisBT") is a popular open source bug tracker written in PHP.

It introduced a much nicer user interface than Bugzilla, and offered more customization, including customization of the bug workflow and state transitions.

Although primarily meant for open source projects, Mantis is a very capable system. We used it for several years at Syllogistic Software prior to development of PMRobot.

2003 - JIRA

JIRA, a commercial product launched in 2003 and built in Java, represented another step forward for issue tracking systems, adding additional customization options, and a powerful plugin architecture.

In addition to issue tracking, Atlassian offers a number of products that integrate with JIRA to help with project management, documentation, and source control integration.

The JIRA platform tends to work best for large enterprise software projects.

2006 - Trac and Redmine

In 2006, two similar projects were born: Trac and Redmine. Both are open-source project management and issue tracking systems. Both offer web-based ticketing system similar to Mantis, along with support for milestones, Wiki-style documentation, and source integration.

Trac is written in Python (a language favored by Google), whereas Redmine was developed on the recently popular Ruby on Rails framework.

Both systems have a multitude of functionality, but their user interfaces can be confusing for beginners or non-technical users. They are targeted towards open source projects, or other highly technical teams.

2008 - Pivotal Tracker

Although it focuses more on agile feature tracking than issue tracking, Pivotal Tracker introduced a number of innovative user interface enhancements.

Its extensive use of multi-column drag and drop allows quick reordering of "stories" (similar to tickets). The UI also allows for one-click transitions between states with buttons such as "Finish", "Accept" and "Reject" easily accessible on the main story list.

Using Pivotal requires a through understanding of the Agile Methodology, and is best suited for organizations that have fully adopted it. The software uses many Agile terms in the interface, and assumes that your process mirrors the built-in states.

It is best suited for organizations that have a stable, fixed team working on long-term projects. Otherwise the "story point" estimation methodology, and overall workflow, tends not to work well.

2012 - What's next?

It's been nearly four years since the last major innovation in issue tracking.

We're seeing a lot of action in the mobile world, but mostly iOS and Android applications to access existing issue tracking systems.

What's the next big thing in issue tracking? Let us know in the comments below.

Monday, December 5, 2011

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.
-

Monday, September 19, 2011

5 steps to estimate software development time

Here's an oldie but a goodie from my personal blog summarized for you here:

Estimating software development time is really, really hard. Here's my method:
  1. Come up with your best, realistic estimate using your favorite technique.
  2. Ok, you have your absolutely realistic number now, right?
  3. It's not realistic. There are aspects you haven't thought of. Double the number. This is your best case scenario estimate, if there are no snags or major changes along the way.
  4. Now double it again. This is your most likely estimate. This is how long the project will probably take.
  5. Now double it a final time. This is your worst case scenario. This is how long is might take if you run into several major issues.
So to sum up:
  • E = Your original time estimate
  • 2(E) = Best case scenario time in reality
  • 4(E) = Most likely time in reality
  • 8(E) = Worst case scenario time in reality
-