Beware the Robotic Horse

I once had a coffee table book covering the early years of the auto industry. It was full of pictures and diagrams of the first crude proto-cars, some featuring these hilarious oversized boilers and even cowcatchers. But the one illustration that stuck in my mind was that of a fully mechanical horse. Some 1890s engineer had actually created a blueprint of a steam-driven robotic replica of a horse, big enough for someone to mount and ride, as if people could not conceptualize a mode of transportation that didn’t look like Mr. Ed. If it moved people, in this guy’s eyes, it clearly had to have four legs and a long face.

IT projects can easily fall into a similar trap. When we redesign a workflow or process, breaking free from the mental model imposed by the current system can be a tough go. Too often we build a solution that (consciously or unconsciously) replicates the existing environment, whether or not it makes sense to repeat all the same steps to generate results. Once you hear the famed expression “but we’ve always done it this way” you’ll know what I’m talking about.

For example, years ago at my last organization I managed a project to automate the generation of standard project contracts. The existing workflow was manual, paper intensive, repetitive, slow, and cumbersome. The vendor’s software package boasted features such as secure online approvals at each level and customized clauses. But the project ended up being canceled before it even hit the development phase. Why? Certain constituencies insisted on being able to print out a contract midway though the workflow, mark it up manually with their red pencils, then somehow have their markups recaptured by the system. They simply couldn’t conceive that editing on a screen was as meaningful as editing on a piece of paper, since that was they way that had always done it.

These customers refused to budge, and the coders soon threw their hands up in exasperation trying to design a technical workaround. It was an impasse that not even the executive sponsors could negotiate through, so we pulled the plug on the project. (And to this very day, years later, the organization in question still devotes way too much time to manually passing around draft contracts.) The famous mechanical horse had struck again.

Designing a “clean slate” solution is easier said than done. Good project managers can prepare for resistance to change by working up front with customers during the requirements definition phase to identify any must-haves that are part of the current process. Great project managers, on the other hand, also have the ability to truly persuade even diehard partisans of the old process that Change Is Good. They can demonstrate clearly that these customers will lose nothing and gain much by trading up to a better technical solution. Such as one with wheels instead of piston-driven legs.

Using basic negotiation techniques can help. Uncovering the "what they want" behind the "what they are saying" is a good start. Customers may tell you that they can't edit a contract without holding a paper copy, for example, but what are their true concerns? Security issues? Being able to convey certain nuances? Discomfort with the user interface? Part of the PM's role is to dig down to this level. Otherwise, the mechanical horse might be rearing up in your future.

Agile Methodology Is Making “Scope Creep” Obsolete

Project managers often list scope creep as one of their biggest headaches. But is documenting all the requirements of a solution before work ever commences truly reasonable? Perhaps what we refer to as scope creep is merely scope refining or scope development, and real issue lies with our own project management methods.

Let’s say that you need to replace your car’s starter motor. After hours of digging into the engine block to remove other components and just access this piece, the mechanic tells you that you also need a new solenoid. Declining to replace the solenoid would be foolish. It would mean another breakdown in the near future and a repeat all of the preliminary labor. So you add the new solenoid to the scope. In a project sense this represents scope creep (plus you will finish over your original budget and with a delayed schedule.) But was it the wise choice? Undeniably.

Traditional project management has long been rooted in “waterfall” development methodogy, a linear, structured approach. This method assumes that almost all requirements are locked down before a line of code is written. Progress is marked more by documents and artifacts such as a DDD (Detailed Design Document) than working code. But this approach can be inflexible and unrealistic when it comes to the demands of 21st century software development projects.

The answer in recent years has been Agile development methods such as Scrum and Extreme Programming. These methods aim at handing over the highest valued functional code elements as soon as possible, and continually improving these elements with each new iterative cycle (AKA “timebox” or “sprint”.) The iterations, which may be only a couple of weeks long, can encapsulate all of the steps of a regular development lifecycle (planning, analysis, design, coding, testing.) In an Agile world the highest development risks are frontloaded, and priorities are reassessed after each turnover.

Agile methods are naturally less bureaucratic, embedding only the minimum processes and controls necessary to manage the effort. Visa visionary Dee Hock once noted that “simple, clear purpose and principles give rise to complex, intelligent behavior…. complex rules and regulations give rise to simple, stupid behavior;” an Agile culture exemplifies this spirit. In this new world, the bywords are collaboration and rapid adaptability. Customer-developer interaction (a big taboo in the tightly controlled waterfall world) is encouraged, delivery of working code is emphasized over technical documents, and even 11th hour changes to requirements are par for the course.

Unsurprisingly, not all organizations have welcomed Agile methods with open arms. Some have characterized it as “cowboy coding” and are reluctant to deviate from their own highly codified and disciplined methodologies. But the stereotype that Agile equates to a lack of discipline or planning are beginning to fade. As current economic circumstances force companies to reassess the business value of complex and burdensome project management methods, more organizations are turning to Scrum, XP or Agile UP. A track record of success stretching back over a decade helps to convince the doubters.

IT projects that have fully fleshed out requirements up front are a rare exception, but too many organizations still run projects based on this premise. Agile methods simply recognize the reality that customers can change their minds. Concepts such as “scope creep” or “requirements churn,” the bane of the waterfall world, no longer have any meaning in this new context. And when working software is the primary measure of progress, what’s not to like?

Do You Trust Me?

Trust. No team can function without it. As a PM stepping into a new project you'll have to work to earn it.

Where to begin? By setting an early precedent that you are reliable and can keep commitments. Within the first 24 hours you need to be demonstrating that you deliver on promises. This can be as simple as adding people who need to charge time to the project into the billing program, or emailing requested documents. The point is to communicate right away that you follow through on commitments.

Imagine the alternative. Let's say you've made a loan to a friend, where they promise to pay you back in installments on the first of each month. Then the first payment date arrives, and …..nothing. Perhaps they just plain forgot and you get the check a few days later. Even if they make the next few payments on time, in the back of your mind, that first impression of unreliability still lingers. Whenever the first of the month arrives, you will still have some doubts about whether or not the check will show up.

A project manager can cement their trustworthiness by reversing this psychology. Reply immediately to emails and voice mails from your project team members. Jump on any problems and make the team aware that you are escalating them or digging for information. Distribute detailed meeting minutes that show you have invested time to get fully up to speed on the project's technology, issues, and action items. And do everything visibly. The message you are sending to the team is that you care, you are responsive, and you can clear roadblocks.

The ultimate goal is not just an environment where everybody trusts YOU, but a team culture where everyone keeps their commitments to each other. So after you've set this precedent, you need to maintain and expand it. Creating more interim delivery dates (mini-milestones,) for example, provides additional opportunity to demonstrate reliability. And publicly recognizing and reinforcing compliance with these delivery dates communicates the priority you give to them.

Lack of trust on a project can result in team members who won't share information, withdraw effort or just do the minimum, or discount others' contributions. And when a team doesn't trust their project manager, delivering a successful project is nearly impossible. Prove your reliability as quickly and publicly as possible and you are off to a great start. Reinforce the importance of reliability among the entire team and you foster a culture of commitment.

In English, Please?

One project management skill group you won’t see called out on the PMP exam is "Translating." By that I mean being able to render TechSpeak to ExecSpeak and vice versa. PMs need to rapidly switch gears depending on their audience in order to explain the same situation in utterly different ways.

Let’s start with business requirements. From the perspective of the developers, architects and testers on your team, the statement of work or requirements document that your customer hands down might seem preposterously vague. “Improve processing time?” “Create a better user experience?” “Build a more reliable environment?” What does any of this mean? How is it quantified? What is the success criteria?

The project manager’s response might be to facilitate a requirements clarification session with the technical leads and the customer, serving as a translator/negotiator to help break down each requirement. Listening, rephrasing, and explaining are the crucial skills (“so what I hear you saying ….”) Through this process, “improve processing time” evolves to “be able to process a minimum of 1000 transactions per minute” and eventually to a detailed set of system changes needed to support this requirement (and finally to a task-level work breakdown structure with dates and deliverables.)

The communication gap can also arise when trying to explain a problem. For example, if development hits a snag, the response from the coder working on the problem can be an endless stream of alphabet soup describing failed job names or mismatched database fields or misaligned middleware scheduler entries. The project manager’s mandate is to distill all of this into a concise “elevator speech” for their client (ie, “the data isn’t showing up correctly because of a problem with the interface to the upstream system; we’re targeting a fix for tomorrow.”) If they want more details, be prepared to explain in more depth. But often times, especially with senior level execs, an assurance that you’ve identified the problem and will solve it quickly is sufficient.

The information needs of executive customers and technical project team members will differ greatly by organization. For example, you may be lucky enough to have a customer with whom you can talk the language of field formats and DNS entries (at my own job, this is often the case) but don’t bank on it. Mastering Exec to Tech translation skills should be high on the agenda for anyone in project management.