In a recent group meeting, a participant talked about his project. The group gathered some information and learned that the project was meant to serve a different group than the business was serving in general.

This created a dilemma for the presenter as he wasn’t sure how to define the group. Would it be those he thought would be the best fit, or should he open up to a broader group? He was stuck in making choices, trying to find one answer that would answer all the questions at the same time.

Without giving oneself a structure there is little chance of coming to a conclusion.

Defining a structure establishes constraints. It tells where to start and how to continue. This is true for developing the project just as much as for defining the service it will create.

What happens frequently instead, is that people search for a perfect answer that tells them how the project should be structured. It’s confusing them as there are too many valid answers.

It’s forgetting that building a project can mean analyzing its definition several times over. Assembling the information, reviewing it, and verifying it always leads to contradictory information that needs to be refined. Instead of using the freedom, this information gives, they lose themselves in perfection.

Agility added the idea that part of the process is to try things out. It’s enabling them to experience how the idea works and how it is received. It doesn’t change the fact that developing a project consists of several cycles. It simply generates feedback to the project in a different way than through pure analysis.

It helps to remember that structure affects process and content.

Once we see how they connect, structure emerges from any choice of process or content.

Choice is the place to start.

Structure emerges as strategy, and endurance becomes how to move on from there.