Model. Test. Repeat.

Project Management


We use our project management methodology to drive deliverables for small and large projects. Our expertise spans a couple of decades and literally hundreds of projects, with a project defined as an initiative that has one or more principal objectives and deliverables with a beginning, middle and end. We recognize that almost all technology projects are attempting to solve “wicked problems.”


A “wicked problem” is one that has the following characteristics:

  • You don’t understand the problem until you have developed the solution. Essentially the problem is ill defined and “what the problem is” depends on who you ask—different stakeholders will have different views.
  • Wicked problems have no stopping rule. Since there is no definitive “problem” there can be no definitive “solution.”
  • Solutions to wicked problems are not right or wrong. They are just “better” than others, or “worse” or “good enough”—there is little objective criteria by which they can be judged.
  • Every wicked problem is essentially unique and novel. No two organizations are exactly alike, and even different functional units within a given organization may have radically different management styles and/or team dynamics.
  • Every solution to a wicked problem is a “one shot operation.” Every attempt made at solving the problem has consequences in terms of time and money spent and therein the “wickedness” is best exposed.

Our services deal almost exclusively with helping our customers solve “wicked problems.” Our project management methodology is therefore built upon the foundation of an iterative approach. This is a “feedback centric” as opposed to “task centric” rationale. That does not imply an antithesis to project plans and statements of work, quite the contrary. However, it does imply that these planning tools are not sacrosanct.

The essence of our methodology can be summarized as model, test and repeat. Our projects plans are built with this philosophical premise in mind. This approach scales from simple projects to those that are much more complex. In fact, it is even more germane with respect to the latter since more is at stake. The “real time” learning that occurs through the feedback loop is the most effective way to manage project risk. The control mechanism used to ensure feedback occurs is much shorter iterations (1-3 weeks, or less) than are typically found in engineering centric methodologies.


1. Model

Our approach in general is to rationalize the decision space. That is, to reduce the number of decisions in progress (DIP) by using proven solutions. This helps to establish boundaries for the solution, but only to a degree. Even with boundaries there are tens, if not hundreds, of decisions that need to be made. The most effective way we have found for further reducing the DIP is to produce a working model and thereby quickly make the evolving solution visible. A model of the solution creates the necessary shared context to allow faster and more effective subsequent decision making.

2. Test

What are we testing? We test the agreed upon "as built" model to ensure: 1) it is "complete enough" to solve our combined understanding of the problem; and/or (and more likely) 2) to uncover "holes" in the model that we jointly failed to appreciate prior to making the model visible. Remember, we are solving a "wicked problem" (i.e. one with a non-trivial amount of social/organizational complexity) and we are modeling and testing in order to better understand the "real" problem.

3. Repeat

The result of testing is that we take what we have learned and build the next model. In this brave new world vendors do not provide solutions, you provide solutions. Why? Because at the end of the day only your team can decide, over time, what the "right" solution looks like for your organization. We help you build a working model. We also provide the necessary training that allows you to modify and improve the model as your understanding of the problem changes. This is an iterative cycle. By definition, your understanding will change because the ecosystem in which your organization lives is guaranteed to change due to competitive pressures in the new economic order.