Preferred Project Development Principles

By Thomas Eklund

For software development quality, timeliness and productivity purposes it matters whether agile, iterative or predictive (Waterfall) software development methodology is being used. Similarly, it matters for software development purposes, and for any business project development purposes, whether or not goal-oriented and self-expressive project development approaches are used in appropriate circumstances.

Over the years I have seen again and again situations where self-expressive project development approach was used in circumstances where goal-oriented project development approach should have been used.

This can cause problems in all the significant business metric areas - quality, timeliness and productivity of the work done, employee and customer satisfaction and retention, and profitability, to name a few broad categories.

I like and respect creative artistic processes. Self expression is at the core of the artistic creativity. So, when I below, and in other parts of this website, explain how self-expressive decision making can hurt business processes, please do not think that I dislike art or artistic creativity. That certainly is not the case.

I am not an artist, but in addition to business analysis, business requirements document (BRD) writing and project management, I have a somewhat unique combination of years of hands-on experiences from the rest of the relational database application development related fields. I also have developed websites and reports. Among other things I have also handled usability engineering and have done user interface design, and have designed symbols and logos, all of which require creative processes.

Further, I would say that programming and other relational database application development areas involve quite a bit of creative decision making as well. The same applies to business analysis and project management. I will also add here that my interest in creativity usage in business processes was largely the impetus that led to my working on CreativityModel Method.

I love the freedom that is inherent in artistic creativity. Yet, I strongly prefer and suggest usage of goal-oriented project development approach whenever objectives or goals need to be defined and achieved. In business environment, that is usually the case.

Both creativity management approaches are useful and needed. It is important to know when to use - or not to use - which approach. This article looks at these topics briefly from the business user's perspective, focusing on some high level aspects that can create differences in project and business management outcomes.

Two Project Development Approaches Compared

The way a project is being developed further, that is, the project development approach that is being used, affects resource usage and quality of the outcome. The goal-oriented approach and its counterpart, self-expressive approach, are described here briefly. Both are related to usage of CreativityModel Method creativity management method. Creativity management and how we use our creativity in the decision making processes, are closely related to project and business management.

In CreativityModel Method context, the goal-oriented project development approach is called Goal Oriented Creative Approach, and the self-expressive project development approach is called Choice Based Creative Approach.

Usage of goal-oriented project development approach necessitates establishment of project objectives and goals at the onset of the project, and then development of the project's structural plan in accordance with these objectives and goals.

So, first and foremost, the project participants need to clarify and agree on what they want to achieve with the project, and how they plan to achieve the agreed on objectives and goals.

Project objectives can be general. In addition, project goals are needed, which should be specific and, preferably, measurable.

Project's structure should be derived from the project's objectives.

When self-expressive project development approach is used, the project development path is largely determined during the project development processes by discrete individual judgments of one or more project participants. Such judgments are usually self-expressively based on individual preferences for what seems to be important at the moment. The total number of such individual judgments that will determine the project's path is usually unknown at the onset of the project.

At any point during the project development process the next project development step may be unknown and may be determined based on the information that emerges during the project development process. Thus, the project development path emerges somewhat stochastically, so that most of the time there are several directions in which the process may evolve.

Usually the project has both a starting point and a general objective. However, among the project participants there may not necessarily be clarity or consensus over what the project objective, scope, development milestones, and resource needs and resource availability are. Further, the project's objective may be redefined either explicitly or implicitly any number of times during the project development processes, without reviewing the relevant project development steps and resource needs.

Because of the stochastic nature of the self-expressive project development approach, it is extremely difficult to provide reliable estimates upfront about project resource needs, such as time and labor. Any such estimates are at the best participants guesses that may have little relevance to reality, which will unfold in discrete steps that proceed in the directions deemed appropriate at the moment.

Self-Expressive Project Development and Management Problem Areas

Most of us live in the world of limited resources. If project objectives are not clearly defined, agreed on and maintained, the probability decreases that these objectives that could be achieved with the available resources will actually be achieved.

When self-expressive project development approach is used in situations that require goal-oriented handling, a project may move in many different directions, without producing any usable results and in the end may produce mediocre results. In the process, way more resources may be spent than the company or organization can afford. If we would graph such project's development steps, the result would look like a chain of zigzagging links, because the participants went in one direction for a while, and then in another direction, and so on.

Each such direction and its length mean usage of time, labor, and often other resources as well.

Such projects may go on and on, without producing the necessary results, without the participants fully understanding what they are supposed to be doing and why. That tends to exhaust the participants emotionally, in addition to consuming more time and labor resources than is necessary. Most likely the same resources could be used more productively elsewhere.

So, even when the negative effects are difficult to quantify, they tend to result in lost opportunities in terms of other projects that could have been pursued, but were not, because the resources were tied up in an unsuccessful project.

Further, both the problems that are described here and lost opportunities tend to create on the organizational level ripple effects that either directly or indirectly affect very many persons professional lives.

Balance Between Goal-Oriented Project Planning and Management Flexibility

Usage of goal-oriented project development approach requires planning, which has a preparatory function.

It is useful to think ahead about what may happen if the project fails or produces negative consequences. The more dramatic consequences any kind of project failure can cause, the more detailed planning is needed.

However, the more detailed the planning processes become, the more time and labor consuming they tend to become as well.

Many business projects do not require very detailed planning, where each project development milestone structure every detail is planned ahead. At the same time we also have to keep in mind that the broader we will leave the gaps between the planned structural parts, the less precisely can we estimate the relevant input needs (technological needs, amounts of labor needed and development time needed), and the more relevant risk we will take on during the implementation.

Even if we will do detailed planning, within each milestone we should leave room for implementation related flexibility, so that we can use the best alternative ideas which may emerge only during project development processes, and may not be available during the planning stages. Accordingly, all project plans that are made, should be considered guidelines and project development navigation aids that are subject to changes. Changes are welcomed, if they can be expected to improve the outcome cost effectively.

When we proceed in a goal-oriented manner, all milestones should serve the project's objectives and goals.

Similarly, all structural parts within a milestone, including possible smaller projects within a project milestone, should serve the specific milestone's objectives and goals.

Thus, any changes that are made to project's structure should serve the overall project objectives and goals as well.

If and when individual milestone goals are changed, entire project's objectives and goals should be reviewed, so that we can be sure that the logical consistency remains between the project objectives and goals and milestones that will lead to achieving them, and the relevant individual smaller projects that are needed for reaching the milestone objectives and goals.

Thus, a balance between project planning and implementation related flexibility is needed.