1 - 2 Project Development: Time

Main Points

• "It's Too Small to be Important." Losing focus on time's value by obsessing over macro-projects.
• "Time to Get Something Done!" Losing focus on time's value by obsessing over micro-projects.
• Using Time Well Think Big... Build Small.

Time is perhaps the most critical component in prioritization. Every organization will identify time as one of their most important resources. Yet many fall into one of two classic time-destroying patterns. One is to fall in love with massive projects because they represent such an enormous benefit. The other is to fall in love with small projects and / or other glitz that distracts from the core things which make the organization successful.

"It's Too Small to be Important."

Looking at the pay off of a particular project is one important consideration in project development; sadly some organizations act as if it is the only consideration. When a known flaw has been around and people are talking about it, you know that your organization is making this mistake. In software development, any known issue that has been around for awhile because it's "too small" or "not important enough" to get a place in the next release is a classic red light telling you your project development procedures are failing in exactly this way. Professional conduct means taking care of all the details, especially the ones everyone is talking about.

The value of the project should be measured both in terms of the pay off and the resources needed to accomplish it. As such it is usually important to adjust the way your organization measures value to pay more respect to time. If a project is quick, that should help move it up the project list because it won't consume as much in the way of resources. That being said, there are a lot of old institutions out there which are making this mistake. So it is usually not fatal; it's just not very professional. At least until a new upstart which has its act together challenges the older organization. Then overlooking the details can be the difference between which organization will rise to the top.

"Time to Get Something Done!"

A second and more serious problem is when an organization falls in love with the sense of accomplishment that comes from finishing small projects. This absolutely can kill an organization. Moreover, it is more difficult to see this problem. It is easy to identify the little projects hanging around an organization that lets them slide. Organizations that are distracted by small projects, on the other hand, usually look very busy and productive. While it is nice to check things off the project list, thinking small is not a substitute for real innovation. You cannot ignore large projects to feed your sense of accomplishment; projects should be addressed based on their value to the core business model.

Worse, this downfall frequently comes in a specific flavor, falling in love with managing emergencies – or falling in love with that which is urgent. If you've ever heard someone excuse a missed deadline because they were too busy with something else, this is a problem. Worse, it may not even be an employee problem, but a management problem. Whatever the cause, managing emergencies is usually the exact Opposite of getting work done.

While occasional one-off projects are a part of life, many emergency projects are the result of an improper procedure. Putting out one fire does not solve anything if the procedure which created it spawns two more. This trap results in an organization whose poorly designed processes are actually creating additional work, not solving it. The most important priority in this case is to correct the process. Only once the process is corrected and you are no longer creating more fires, does it make sense to sit down and put out the fires which are raging. Perpetually resolving emergencies is called Emergency Centered Management (ECM), and it is one of the classic anti-solutions. In fact, it's such a glaring anti-solution that a couple examples ought to highlighted to demonstrate its seductiveness and apparent effectiveness...

One, support departments which measure effectiveness based on the number of tickets resolved are a classic demonstration of ECM. These departments are almost never effective. On the contrary, they only look good if they adopt processes which create lots of problems that need to be solved. Thus the most "effective" ticket-based support centers are typically classic examples of everything that you should Not do. They create simple, well-known problems which can be easily resolved without ever fixing the processes which created the problems in the first place. Equally problematic, complicated problems arise in every business, but because they take too much time to solve, "effective" ticket-based support departments solve this issue by misidentifying the problem. By ignoring the underlying problem and dealing only with symptoms, they can patch or gloss over issues and continue to turn out rapid-fire "solutions"; however, this does not get at the root of any of an organization's challenges.

ECM is also a feature of some "high-performance" "fast-paced" office environments where the thrill of operating under the gun has become an adrenaline rush which trumps developing effective procedures in the first place. People who work hard are a good thing, but it's better if they work smart instead. "Work smarter not harder." is one of the catch phrases which define office life in the 21st century, but many offices pay it lip service rather than actually implementing it.

Unfortunately, these very busy offices are creating more work than they are resolving. This is not unproductive; unproductive means you are not doing a good job of completing projects, rather it is anti-productive because these offices are generating new work in their constant desire to amp up the energy level in which they find personal satisfaction. While they may "look" like they are accomplishing so much and everyone "seems" to be performing at 110%, in reality they are trapped. These offices routinely pass over the most important projects because they are seeking the personal satisfaction which they find in accomplishing the most Urgent project.

In the completely self-destructive conclusion to this anti-solution, ECM generates a tolerance, even an expectation of failure. What starts out as a few fires produced by poor processes slowly grows to the point where all the fires cannot be handled. Projects necessarily become unmanageable under the sheer volume of work to do. However, this is the goal to which these offices have aspired, a constant barrage of issues capable to satisfying the most battle-hardened adrenaline junkie. Yet, failure is never a problem in these organizations. There are always plenty more fires raging. In fact, it should be obvious that a key part of the "success" of this business model is to avoid the let down of the latest failure by blasting it out of your head with the next fire. You can spot this anti-solution; observing the speed with which people rush through the halls of the office is one way. Also, people are usually so consumed with urgent tasks that everyone routinely fails to show up on time for meetings.

True effectiveness comes from the steady and efficient identification, prioritization, and implementation of quality projects. Appreciate a project's real value and give it the respect and attention that it deserves, no more no less.

Using Time Well

Time is certainly critical enough to warrant keeping your eyes open for warning signs like these. However, here are some key tips to use when prioritizing your project list.

Err on the Side of Big Projects

The consequences of ignoring small projects are usually measured in the irritation of stakeholders, especially clients. This encourages the perception that you don't care about the little things, or that you're sloppy. Left unchecked, it creates the perception that you don't care at all. None of these are good things. However, the consequences of ignoring large projects can be project failure, and even organizational failure. These are not balanced consequences, and your priorities when determining the final project list should reflect that. All else being equal, take on the bigger things first.

Design should also consider the larger situation of change and the interfacing modules which already exist in the current project and those on the project list for the future. Working on a small focused design is unquestionably easier, small projects really are easier and more efficient than large ones. It is certainly possible to manage your time more efficiently by breaking larger projects down into smaller ones... for construction. However, if you fail to design with the big picture in mind, you will have to come back later to recode the system when its poor integration becomes a problem. Or worse, there are organizations which simply ignore this lack of integration which is the quick and easy path to maintenance hell.

Build Incrementally / Iteratively

Design a little, build a little, test. The longer it takes for you to get around to testing something, the more code you have to look through to find the error / oversight. During detailed design, you should identify increments which you can build and test complete. These will become important checkpoints for more thorough testing. Individual developers benefit from testing a few lines of code, but your team should always systematically hit checkpoints during construction. The site can then be pushed to a test site for more detailed evaluation; if you have a QA department this is a logical place for them to take over while still being able to work with the development team throughout project construction to identify issues as early as possible. That way you can avoid writing new code that's based on bad code. This is why incremental development is so valuable.

A corollary to this is to use iterative development methodologies. Smaller projects are more efficient to build because they are easier to understand. Abstraction helps you break a large problem down, but dealing with a fundamentally smaller problem is even better. Iterative development identifies small projects that you can build to grow an application piece by piece. This can be accomplished by breaking a big project into modules, with each piece adding different functionality. You can also build the core of a large project and then progressively extend it into a larger project piece by piece. Either way, it is more efficient to build small than to build large, and this is why iterative development is a best practice.

There is another less than perfect advantage of iterative development, but one that is no less significant. Sometimes you can take a large project and break out a smaller project which incorporates an especially difficult, complex, or otherwise risky module. Risk Management operates by front loading the most difficult tasks; this minimizes the effort lost if a project fails. Using a small project like this effectively moves key risk management portions of the large project before its own development even begins. Developing a small application which fails loses you only a small amount of time and code but still demonstrates a make or break flaw in the large project; this is fantastic compared to losing lots of time and code on a large project.

Build on the Code You've Already Written

You built it, take advantage of it. 3rd party software can cause problems because it keeps useful helper functions hidden away, and doesn't integrate nicely in other ways with your application. This is one of the big strikes against it. There is no such down side to extending your own code base. On the contrary, using your own existing architecture ensures good reuse of functions which decreases your time of construction. Using the same helper functions rather than writing them over prevents WET "Write Everything Twice" code. DRY "Don't Repeat Yourself" code minimizes maintenance time. Reusing your code base also does more than anything else to force developers on the team to work in similar ways. Similar coding techniques gives the team freedom to assign anyone to work in any portion of the application on any author's piece of code, and they will still have a basic familiarity with the code they are working on.

Prefer Saving Time on Maintenance to Saving Time on Construction

Coding an application is a long term issue. Research has consistently shown that despite the huge amount of work which may go into construction, maintenance is still the phase of the SDLC that requires the most development time and monetary expense. The percentage for iterative development projects is even more extreme. This is the other big reason that 3rd party software can be an "illusionary" benefit. 3rd party software by its nature sacrifices maintenance time to save construction time. If a 3rd party application or a framework makes maintenance more difficult, you are probably creating more work than if you used custom code.

Further, maintenance is a viciously sneaky phase. If you look at the SDLC, maintenance looks like it's very well contained, something that happens following deployment. The problem is that construction does not happen in the snap of a finger. The fact is that construction takes time, frequently more time than any other phase except maintenance. Here however is the dirty little secret. Once you create the first function, or class, or module for the project, that piece is now effectively under maintenance. While universally treated as "construction" resources and expenses, in terms of how you are required to approach the continuing development of these pieces, they are fundamentally maintenance issues. If you have sacrificed maintenance considerations to "speed" construction, you begin paying for it as soon as you've typed in the last character. This can have a devastating impact on construction and has caused more than a few project failures.

The key thing to remember is that time deserves the credit which it is due. When prioritizing a project list, don't forget to account for it sensibly. It is easy to become enamored with large or small projects but ideally you should steer the middle course recognizing a project's value and prioritizing it appropriately.