Process Makes Perfect

The technology project manager's job is somewhat mysterious to the uninitiated. dataSpheric lets you in behind the scenes. In this article we see how the "project process flow" translates to real people in real time.

At dataSpheric, if we havn't done it, we've done something like it. Our approach to development is highly systemized or process—oriented. This isn't to say that great flexibility is called for, but the core process is carefully protected.

This article first shows you our in—house solutions template which is a serial template. This means that the activities or logic described is linear—one activity or object is placed before another in a clear path from beginning to end.

A serial production path, however, does not describe the activities of the people writing the software. It also doesn't describe one of our core methodologies in website developement: RAD or Rapid Application Development. The next two charts you see will describe the parallel nature of work on a typical web project which means that many activities are occurring simultaneously.

Now that you know what's coming, let's get started. Below you see our in-house development path. As the client (or our competitor), you usually doesn't see this.

There are three critical gateways in our development path that determine what methods will be applied. They are:

1. Is this web-enabled software or is it "flatware"? Arguably, every web document is software in some sense but for our purposes we make a distinction between software that "does something" and software that simply "displays something".
2. Does this web site require search engine marketing or search engine optimization? If so, there are major ramifications for research and content planning.
3. Will this site be constructed in our usual standards-based CSS/XHTML or will it require other modes of markup?

Of course, all of this simply describes how we work and what key determinations need to be made in developing a software solution. The real knowledge that we need to leverage as business solution developers is to be found with you, the client. You have the expertise and vision that we need to express in software terms. Our Web Project Requirements Gathering Explained page helps you understand how you fit into this crucial process.

While it's true that our process remains essentially the same for all projects both great and small, getting the project done right involves many simultaneous activities by many qualified people. Below is our diagram for basic project process flow. Again, this chart is serial, with activities arranged linearally through time. It sort of re—states the chart above and gets us set up for the parallel activity.

Let's take some time to explain it

The essential parts of a web-enabled software project are:

Preproduction

...where we identify the need and requirements for a solution. Preproduction is a highly interactive effort that requires input from your organization in a carefully guided process that unlocks creativity and produces fresh insights for your business. We also carefully model out the solution, we may utilize a prototyping phase for more complex projects and we make careful ROI (Return On Investment) analyses. A successful preproduction process concludes with a finalized project specification. Your organization has a crucial role to play in this process, specifically in the Requirements Gathering phase. We are additionally diligent to perform Risk Analysis for mission-critical projects. No Phoenix web site company is more comprehensive in their preproduction process. Preproduction concludes with an approved project specification.

Production

...where we execute the project specification. In this phase the database architect, the programmers, coders and designers get to work in a highly efficient "parallel process". This is an ingrained habit of RAD (Rapid Application Development), another factor that makes us unique as a Phoenix web site company. Careful planning reflected in the project specification make this a fast process. Production concludes with a successful deployment.

Postproduction

...where we evaluate our solution results, place the project in maintenance phase and conclude the project. Plans are set for reevaluation of the project based upon predetermined metrics. A final document indicates the location of source code, it's documentation and the return of other intellectual properties.

The essential constraints of time, cost and quality are monitored throughout.

The red vertical lines below represent natural "stopping points" in the process where development can be safely concluded and documented to be theoretically continued in the future without significant loss of intellectual property, time and effort. It's a fact of business life that budgetary constraints, change of strategic objectives and other factors can squelch a project before it ever launches.

Nevertheless, the whole thing looks simple in the chart above. The activities, or project phases, are arranged linearly, serially through time. You start, go through the process and finish. Pretty reassuring, right?

In reality there are more roles at work, more interactions between various team players. If we were to visually represent them all for a typical Phoenix web development effort with a dynamic, database driven architecture and if we were to represent all of the activities as they happen in time it would look like the picture below:

The first thing you notice is that there are a lot of overlapping activities. This reflects the fact that a lot of people are dong a lot of different things at the same time. Now, you may ask, why don't they do all these things at the same time? The answer is that most of the people involved depend on the work that has gone before them to do their jobs. The copywriter depends upon the content outline. The web designer needs the content outline to anticipate page length and so forth. Each person in the team, whether it be your strategic stakeholders or our development staff is involved in a highly interactive process through the project development process.

Returning to our flowchart, you can see our basic outline is still there. We have our three major phases, preproduction, production and postproduction. We still have our key steps and outputs. In addition we have the activities that typically accompany these phases in an arrangement that indicates how they relate to each other chronologically over the course of the project.

Understand that the flowchart above reflects a careful balance of what "should be" and what "often is". For instance, notice how the block titles Technical Solutions Definition extends beyond the "Solutions Definition" cutoff point. How can a solutions definition process continue beyond itself? It makes no sense! It's like asking how much longer a dead man will live!

Well, before you people rise up as one body and with great moral indignation accuse me of being illogical, allow me to explain: one word: prototyping. Quickly explained, we frequently know what we want to get accomplished, we frequently know how we want it to look, we know where we want the data to go but for some reason or another we're not yet sure exactly how to actually do it. Similar anomalies exist, you'll notice that the Deployment And Rollback Plan Initiated extends just a bit into deployment. Again, I may as well come clean. On some projects, with a tight schedule and budget and a worn-out team, we're frequently well into deployment planning when I blow the whistle and point out that we don't have a rollback plan-a "what if it goes boink and we have to put it back the way it was" plan. In technology, especially mission-critical web-enabled software projects, you absolutely, positively hedge your bets. Careful risk analysis and contingency planning are essential.

Each of the activities represented in this project is the responsibility of a specialist in his or her field. If we were to list out the expert roles involved in this project they would be:

• Key stakeholders
• Financial consultant/Accountant
• Legal counsel
• A representative from Marketing
• A representative from P.R.
• People who will be using the system
• People who will be supporting or "hosting" the system
• Database expert
• Coders and programmers
• Designer
• Copywriter
• The Project Director (the client's representative in the project)
• The dataSpheric Project Manager

Now I'll just tell you the truth. As you look at our project management templates, even in spite of the confusing and complicated flowchart you've just seen, you might be tempted to think that us project managers have a predetermined answer for everything. This brings up a number of interesting observations: we might look like we do, we in fact usually do if we're seasoned veterans, but a technology project, unlike the pure, rational realm of code, is a human thing.

Never once in your life, as a project manager, forget that it's about people. It's always about people. Web-enabled software is about real people in real time.

Because of this human factor, great amounts of unpredictability come into the equation. And here's where I really level with you: projects are in fact highly fluidic, dynamic things, wiley as snakes, they writhe, squiggle and squirm. It takes a firm grip and an impervious countenance, a great poker face and a thick skin to be a technology project manager. Because the project must succeed in measurable terms, it's own metrics, or else your career is cooked as a technology project manager. And technology, the metrics we use, do not cover for failure. You cannot run, you cannot hide and the very first place they will come to lay blame is YOU, the project manager. You are, after all, responsible for project success in it's entirety. And every time, the question in reduction comes down to this: how well did you serve the people?

Knowing what kinds of information these people need to do their jobs, to use the software, to get their job done is as important as knowing when they need to be doing their jobs. Coordinating all of these activities is just part of the dataSpheric project manager's job. Knowing the kinds of input and expertise your project will need ahead of time puts you one step ahead of the game. It also helps us to understand the real cost of the project for your company. Time is money. Our software has to make it back. We're not just any Phoenix web site company, we're dataSpheric.

Now if this or any of our management templates helps you out, helps you anticipate pitfalls, helps you succeed then our time has been worth it.

 Contact us today and we won't put the marketing jib-jab on you. We'll give you fifteen minutes or a half hour of our time on the phone or by email, talk about what you need to get done and probably give you some advice you can take to the bank.