Posts in  patterns


Pattern: One Clearly Defined Project At A Time


All the time.


Prefer working on one project at a time. Finish it before moving on to the next. The project should have a definitive start and end centered around clearly defined business objectives.

I don't mean to suggest you shouldn't have multiple projects in your work life. Just prefer to minimize the number within a context, say a team of people working together. That said, there is value in minimizing the number of teams you are involved with :)


A common issue in software development is run on development. This introduces many risks:

  • Failure
  • Budget overrun
  • Infrequent delivery of results
  • Inability to measure success/failure of investment
  • Vestigial feature explosion
  • Incomplete feature explosion
  • Confusion about what the software does
  • Confusion about what the software should do
  • Buggy software
  • Lack of real world feedback
  • Lack of learning - reflection rarely occurs
  • Lack of trust - trust is built on results
  • General sadness for everyone as the work drags on with little or no results :(


Constrain each project based on a set of business objectives. Keep the list short and projects will start and end quickly.

If higher priority objectives arise, decide if they can wait. Ask what the value of doing it now versus a few weeks or months from now. If there's really no value (other than maybe excitement) then wait! If not, then decide what to do with the current project.

In my experience, working on clearly defined projects one at a time means we spend less time on each project, we know when we are done and we can quickly move on to the next highest priority objective. This often negates the need to interrupt a project.

Tips for interrupting a project

  • Replacing objectives - New objectives replace current objectives
    • Craft a project to address the new objectives and in the process discuss what has been done for the current objectives.
    • Determine what should remain
    • Determine what should be removed - if the objectives change there are going to be features that aren't necessary. Get rid of them or be prepared to pay to support them in the long run.
  • Different objectives
    • If at all possible discuss how to wrap up the current project with a subset of the objectives accomplished.
    • If that's not possible, put the work aside and switch gears.
      • Plan a time to come back to the current objectives. It's easy for months and years to pass. These easily become features that you may not get any value from but you pay to support.
      • If new and current objectives affect the same system, discuss removing or setting aside the current work so you can focus solely on the new objectives.

Pattern: Establish Trust First


The first few discussions with a new consultant.


Ease into starting a project with new consultants. First invest in building some trust.


The first discussion is a great opportunity to talk about your business with the consultant. This understanding is invaluable and should be easy to talk about without advanced preparation. In subsequent discussions gradually introduce goals and problems.

Shared understanding is a great way to establish trust. Look for ways a consultant offers value through past experience, advice, and other feedback. This initial value can go a long way towards establishing trust.

Not to mention what it means for a consultant to invest the time to learn about your business and showing interest in what you do. Holding several discussions gives everyone a chance to reflect and bring even more to the table in subsequent discussions. This can be a quick way to weed out consultants that don't have the time to deliver quality solutions.

This is also an opportunity to show the consultant that you are willing to invest the time to build a quality solution.

Wouldn't your rather learn a bit about each other to see if the relationship will be a good fit?


  • Make the first meeting only about your business.
  • Subsequent meetings can lead into objectives (goals and problems).
  • Assess the trust you have established, keep notes!
  • Avoid talking about solutions in these meetings. Solutions in software development often take significant time to develop. Work on establishing the trust necessary to justify investing time in devising solutions.
  • Avoid talking about costs in these meetings. Costs are unknown before a thorough analysis of solutions. Instead talk about pricing methodology to determine if it will fit into an investment model you are comfortable with.

Pattern: Reduced Risk Initial Project


The first few projects with a new consultant.


While taking on the risk of working with a new consultant, minimize other risks including time, complexity and low value. Nothing builds trust like a completed project that meets your objectives!


  • Minimize Time - Work with the consultant to identify a project that can be completed within a time-line that is quick for your organization. I would recommended something around a month or less.
  • Avoid asking "Can X be done within a month?" Instead let the consultant identify the time-frames and compare relative time-frames to find the quickest projects.
  • Ensure that quick does not mean rushed. Quick means there isn't a large time investment. Rushed means efforts will be doubled up which actually increases risk.
  • Stick to a simple objective with clearly defined value and simple measures to gauge progress. This will lead to a much more definitive end of the project.
  • Maximize Value - Make sure the project is of high value. It's exponentially more difficult to build trust if there's not much value to be gained from the relationship. High value leads to better commitment on both sides. Honestly, I never recommend low value projects, I've never found a company short on high value projects but I've seen plenty of low value projects get in the way.
  • Avoid Complexity - If you have a set of projects that seem equal in value and time, pick the least complicated project. Complexity almost always leads to unknown risks.
  • Be prepared to discuss several sets of objectives to see which project minimizes these risks the most.


  • Complex, higher value projects will have to wait.