Bob Lambert

Recently I was asked for a high level requirements plan for a large IT conversion.  I googled around a little for something standard.  I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people.   I then rifled my files to find the example below.

This summary plan frames up interactions with business subject matter experts and their review of results.  The table lays out the steps, “granularity” (meaning how often each step is carried out), what comes out of each step, who does the work, and offers a few notes.

Before the table, here are two important definitions:

• Sponsor: Very early on in your project you should identify the one person who you need to make happy in order to succeed.   The bigger the project, the higher up the sponsor.  Keep in touch to make sure they know what’s going on, keep them happy, and if something happens that will make them not happy don’t keep it secret.  Maintain a vibrant risk/issue process so that you can give them early warning of bad possibilities and they can help early.
• Stakeholder: A stakeholder is anyone who will benefit from or be harmed by your project.  Requirements come from stakeholders.  Be sure to build support even with the latter group if at all possible, and at least make the adjustments that will keep them from working to prevent you from succeeding.

Careful, this is just an empty vessel.  Within this high level framework a team can apply whatever requirements techniques they want.  (In fact, I highly recommend structured analysis techniques like use cases or process models, but that’s for the requirements team and this framework is for the PM).  Of course a smaller effort suitable for agile techniques wouldn’t need something like this.  This is for big transitions like conversion to a new COTS package, for example, where it is easy to get lost in the detail.

Hopefully if you’re a PM on a big project you’ll find this framework as useful as I did.

 Here are some of the other references I found along the way, caveat emptor:

• http://www.outsource2india.com/software/RequirementAnalysis.asp
• http://en.wikipedia.org/wiki/Requirements_analysis
• http://www.jiludwig.com/HCI_Journal_article.html

To me, calling someone a “user” contributes to the gulf between IT and other business people.

Most of us don’t think about it and say “user” or “end-user”. Those who do think about it say something like client, customer, or business customer, or something similar.  Sometimes these terms work and sometimes they seem contrived, but there’s a better way.

Lior Arussy of the Strativity Group argues that what we call our customers is critical to effectively serving them (http://www.crmxchange.com/focus_customer/Oct06_2.asp). According to Arussy the problem is that many of us use terms for customers “based on their role in our process, encouraging a “one size fits all” approach that treats all customers the same. The diversity and complexity of customers is subsequently ignored and replaced with a customer that does not exist but who fits perfectly within the organization’s business model. The customer is thus subjected to the company’s processes and efficiency needs rather than the other way around.”

When we in IT call them “users” we do the same thing. Rather than thinking about a business person’s role in a business process, we think about them in terms of how they use “our” system. This encourages us to think narrowly about how, for example, a recruiter uses a personnel workflow system. The word “user” encourages us to disconnect from the business process rather than understanding how the system fits into the hiring process as a whole.

Maybe I’m exaggerating and this one small point doesn’t matter much. However, in most organizations there is a a communications gap between IT and business, and as the service provider it is IT’s responsibility to bridge the gap. Communications gaps are made up of lots of little habits of thinking and practice, and this is one of them.

So what should you call the user of a business application? When I’m talking generally about business people who use IT applications, I use the term business people, which after all is what they are. When I’m talking about the users of a specific system I try to use the term that everyone else in the organization uses for what they do, like “financial analyst” or “recruiter” or “production line supervisor.”

I hope that being specific and correct about business people’s role encourages me to understand the system I’m building in business context, making it easier for me to build the application exactly as they need it.

I’ve heard that “A good project manager can manage any project, as long as they’ve got good people on the project”. In the perfect world, maybe. In the real world, no way.

Those promoting project management focus on characteristics of PMs that are common across all disciplines: interpersonal skills, organizational skills, communication skills, and problem-solving skills.  These are necessary but not sufficient qualities.  Good project managers also have interest and depth in the subject matter of the project.

It seems that the world has forgotten about history’s great project managers. They were overwhelmingly individuals with abiding interests in their fields.  Werner von Braun led the massively successful development of the Saturn moon rocket. General Bernard Schriever, the man cited as “The Father of Project Management” (here), who led the Air Force’s space and missile programs in the 1950s, was a long time pilot with an engineering degree.  Frederick Brooks, with a PhD in Mathematics from Harvard, led development of IBM’s OS/360 operating system, fundamental to IBM’s dominance 0f commercial computing during the 70s and 80s. “As of 2008^[update] he is still engaged in active research there, primarily in virtual worlds and molecular graphics.” (Wikipedia)

I recently witnessed two IT projects, both multimillion dollar efforts and both business-critical.  Project A, a migration to a commercial-off-the-shelf (COTS) human resources system, tracked to budget and schedule and met business objectives with almost no customization.  Project B, another COTS effort for core business operations, suffered huge budget and schedule overruns associated with frequent changes in direction and scope expansions.

Project A was outsourced to an outside consulting firm, who brought in a PM with deep technical experience configuring and customizing the COTS package.  Project B was run by an internal Project Management Office, staffed by project managers who did not have technical or business analysis backgrounds.

Project A’s leadership had the background to understand the road ahead, and spent six months of a two year project in definition, completing detailed business requirements, business process design, and system architecture deliverables.  On Project B, a senior IT manager decreed that the team skip requirements definition, since future business processes would be dictated by the COTS application: a critical early mistake.  Project B’s management did not have the IT background needed to recognize the mistake, which would have been obvious to the Project A team.

For a PM to be effective he or she needs sufficient knowledge to envision the end product in a scope and objectives document, create a work breakdown structure that makes sense to business and technical team members, and know which risks are pivotal and which don’t matter.

In spite of stereotypes about IT folks, many are experienced, articulate, well organized, have great interpersonal and problem-solving skills, technically curious, and would welcome an opportunity to lead an ambitious project.  Make one of them your project manager, provide strong organizational support, and you’ll be more likely to achieve objectives on budget and on schedule.