Managing Creativity and Complexity


Most people who enter the IT profession want to be “developers”. They want to create new and exciting capabilities and not be stuck supporting existing systems. Sounds exciting but managing the creative process is a manager’s worst nightmare. How does a manager address the following questions?

1. What is the quality of the results from the creative process?
2. How long will it take?
3. How does anyone know when they are done being creative?
4. What skills are required to be creative and who has them?
5. When does the creative process occur within the life-cycle?
6. How do we ensure consistency of application behavior when each individual developer is making their own creative decisions?

Failure to manage creativity injects a substantial amount of uncertainty and risk into our projects. Today’s development tools allow developers to design and develop at the same time. They have thousands of options to choose from including database design, colors, graphics, object types, etc. that are arranged into a continuously mutating prototype. By the time they are forced to complete the assignment, the components have already been modified hundreds of times resulting in code that is highly complex, heavily modified, inadequately tested, late and over budget.

Does this sound familiar? What impact does this approach have on your projects? Imagine the chaos that would result if we constructed buildings or cars using this approach. Would you want to drive one of these cars?

What can be done to manage creativity and complexity to solve this problem? Take a lesson from the construction industry. Architects complete the creative rendering based on general requirements from the customer. They do not ask the customer to design the building nor do they allow the plumber and electrician to design their own solutions. Once the Architect finishes the creative rendering, a draftsman creates detailed blueprints, and everyone else’s job is to build it according to the blueprint. How do we implement this approach in IT projects?

1. Create position and career path for a design architect who can assume responsibility for the creative process similar to a building architect or a design engineer in the automotive industry.
2. Impose a deadline on the creative process.
3. Keep the creative process at a high level. PMI describes “progressive elaboration” as the mechanism for gradually defining lower levels of detail. Evolving detail is not the same as constantly changing the design. Specifications should simply provide lower level details for implementing the initial design.
4. Provide the customer with an opportunity to view the initial “rendering” and concur before detailed design or development.
5. Defer changes till the end unless they will result in significant re-work. Once the initial capability is build, organize the changes and implement them as a follow-on project.
6. Build the application using a modular approach that allows flexibility and allows future changes to be organized by module.

These suggestions are common sense. Why aren’t more organizations taking this approach? Simple: Everyone wants to be a developer even if they lack the design skills to be effective. Senior people are assigned to support production systems while new systems are designed and developed by junior staff. Finally, we are also in a hurry to begin development so we don’t spend the time to develop a workable approach as expressed by one of the oldest jokes in the IT industry: “You start coding while I go figure out what they want”. I heard this more than 20 years ago and it is still true today.


About Author

Comments are closed.