This is the stage of a typical Interactive/Software Development Lifecycle where the rubber meets the road. By this point in the process the Strategist has assisted the client in identifying specific desires and establishing metrics for them (Part II: Discovery). There is a formal Scope of Work, Estimate, and Project Plan made (Part III: Definition). The Information Architect has established the basic structure of the interactive experience and the Creatives have stepped up to translate the wireframes into key visual comps or designs (Part IV: Design).
Now it just has to be built. Piece of cake, right?
Development is going to be one of the more difficult phases for the average Project Manager to wrap their head around when it comes to making plans, scheduling, and performing schedule adjustments once the project is underway. This is due 100% to a communication barrier, a veritable chasm which splits any agency into two distinct groups: those who code, and those who do not.
The language barrier is a simple one, and very easy to overcome once the PM is aware of the dynamic involved. The simple fact of the matter is that a coder speaks a language which requires an exacting level of precision and accuracy, a level of precision and accuracy which is typically misunderstood and completely unappreciated by non-coders. Ironically, earlier in this series I focused on how Project Managers typically feel frustrated because *we* tend to use language very specifically as compared to everyone else on our team, and yet it’s the exact same dynamic which can result in a developer agreeing that yes, doing things this way is certainly -possible-. In software development, really, given sufficient resources, time, and expertise, most anything is ‘possible’. This is why it’s very important that PMs on any sort of interactive team need to cultivate a relationship with the folks in development, and they need to take an active interest in learning as much about the big picture of what’s going on inside the Development process.
The Development Process
I’m an outsider to the development world myself, so allow me to present the extremely broad strokes for what Development actually entails. First, the Developers are going to want some sort of an official hand-off once the project is ready to move into Development. Coders tend to appreciate linear and specific instructions. So provide them with linear and specific instructions, or else turn the Development Hand-Off meeting into a time when you can work with the Developers to jot down the outline of their linear and specific instructions.
In an ideal world, the Business Analyst or the Information Architect has already generated Functional Specifications to go along with the Wireframes. These two documents together provide the best starting point for any Development team because those documents contain the specific plans that the Client has already approved. The Developer can now check the Func Specs instead of trying to translate the PM’s response to questions about what the Client wants. The Developer can look at the overall effects being called for in the Wireframes or Use Case Scenarios (“on rollover, display X from Wireframe 3.2.12”).
Once the Developers think they understand what’s being asked (note the relative wiggle room in this statement), they will then begin to apply their own brand of planning and execution to things. It will start with the Developer opening up the code and “taking a look under the hood”. There’s more than one way to write code for most complex tasks, to the point that several coders make the case that writing code is a form of literature unto its own. It communicates the mental state of the original coder. That’s why, unless the development team is building from scratch (and even then they should be repurposing code structures from other successful house projects, not reinventing the wheel) it’s always possible that the Development team will return quickly with bad news… “The project’s going to take a lot more work than I thought.” Why didn’t they flag this earlier? They hadn’t opened up the code until then.
First build it, then break it
Then the coders get to work. This is where the Keebler Magic happens. The coders will begin a staring match with their computer screen and alternate between lots of clickety-tappety, lots of frownity-glare-ity, and random bouts of cursety-swearity. (Those are technical terms. Don’t believe me? Watch a coder at work.) First they’ll build the code. Then they’ll do everything they can to try and break it. Once things have gotten to the point that the Developers get bored with breaking the code, they’ll declare it done and turn things over to the QA process. Anything that happens beyond this point will always and unfailingly be someone else’s fault. Doesn’t matter who the coder is. It just sort of comes with the territory.
All along while the actual coding is going on, the Design is also likely being put together to work in an interactive environment. As Development nears a close, any of the heavy-lifting that the back-end developers are doing will eventually be married to the front-end Design-heavy coding that Production Artists are doing. Adjustments are made until it all synchs up right, hopefully on schedule.
QA, you say?
At this point Quality Assurance will take over. The project will most likely be put up in some Staging environment (which means it’s NOT the place where the project will ultimately find a home). Staging environments are usually password protected, but sometimes protected by the complete lack of interest that anyone has in half-baked projects anonymously posted without any advertising or push for visitors to get there. In smaller shops, QA is handled by a coder who didn’t actually code the thing. In larger shops, QA is a separate career specialist who focuses on finding as many mistakes as they can.
QA will then try to interact with the project on a variety of different computers, different browser versions, and different communications platforms (like Mobile) when appropriate. The QA person will look at the Func Specs, Wireframes, and Use Case Scenarios and check to make certain that everything works right and looks right. Their job is to find all the errors possible BEFORE the client takes a look at what might be a broken program or page.
Quality Assurance is actually one of the steps in the process which fits equally well in both Development and Deployment. I personally favor putting QA at the end of Development, because QA is handled internally. If there are any errors to be found of sufficient intensity, then after QA is done the project will return to the Developer to fix or update things as needed. It’s only once QA signs off on the project, or once the Developer has made all of the fixes and overruled the QA process that Development truly ends.
What to Expect As a Client
If you are working with a team for the first couple of times, you can expect there to be some bit of learning curve to happen in the Development phase. This is a difficult phase for the Client side of the house because while the Developers are happily clickety-clackety-ing you won’t see anything, or hear anything, or be given anything to sign off on. UNLESS there’s a change to the scope, or unless the developers got knee-deep in someone else’s code and discover a huge problem that couldn’t be foreseen otherwise, no news is good news but the wait can be uncomfortable for clients used to more of a micromanagement style.
This is the part which can be frustrating for another reason, too. A more subtle force is at work here, and that’s the fact that Coding is much more an exercise in Creativity than it looks like from the outside. There’s often a couple ways to accomplish the same intermediate steps, but putting them together one way will empower more robust use of those features and functions at the end, while combining them in code a different way could actually PREVENT the development of more complex features down the road. Because of this variability in coding methods and informational structures, coding can be a very personal matter. In larger development houses there will be a House Coding Style and standard which the shop is expected to follow. In smaller development shops, it’s up to the individual developers.
Because of this, you run into what I call the ‘pregnancy trap’. The old office chestnut goes like this. “It takes a woman 9 months to bear a child, but if I give you 8 other women does that mean I can have the kid in 1 month?” The pregnancy trap. Certain efforts need to be assigned to a single person, or a dedicated team that works on things from start to finish. If you’re working on a ‘pregnant’ task then adding more people won’t make the process go any faster. Some things in life just take as long as they take, and they can’t be hurried by throwing more money or more resources at it. Developing, more often than not, is exactly like that. (Except when it isn’t… building a trust-based relationship with coding teams can make all the difference. Until client, PM, and developers trust each other, or at least learn to trust the PM, this phase will produce round after round of unexpected troubles.)
Obviously, trust becomes a huge factor here. Since Developers are usually kept far away from the Client in many organizations, you’re going to need to trust your Project Manager. One thing that you can do to alleviate stress in long-term development cycle projects is to ask the PM to set up periodic checkpoints WITHIN the Development phase. They don’t have to be client reviews, but just times when the PM estimates that different pieces of coding will be done. From there, the PM can simply review where the project actually -is- during the Development phase without trying to coax the Developers from their keyboards.
Once Development is done, User Acceptance Testing — the part of the project where the Client gets to try everything out — will begin, and UAT is where I mark the formal start of the next stage…. Deployment.