Posts Tagged ‘requirements’

If you knew at the beginning of a new project that at the end of 6 months, or 8 months, or $50,000 or $500,000, there was going to be an abrupt halt, your project deemed a failure, that no extension was going to be given, that the project concept would be tabled for a minimum of two years, how would that change your approach?

If you could then look in your crystall ball and see 2 of your development staff leave during the course of the project, one to another job opportunity, the other hit by the infamous bus, what would you do differently in the beginning?

If you knew that after the successful delivery of your solution to market that somebody would get a job as a result, or all restaurants in a chain would be able to keep their beer fridges well stocked, or it would cause the prompt delivery of a replacement kidney to a hospital, how would that effect your gameplan?


Read Full Post »

I was reading a fun book on public speaking, Scott Berkun’s “Confessions of the Public Speaker,”, and he referenced a TV series he contributed to, CNBC’s The Business of Innovation, so I checked out some youtube for it.

During the first few moments, one of the experts declares it’s all about getting the Business People and the Scientists on the same page. I agree, we need to amend to this “without violating those individuals’ personal 80/20 rule.”

The more you force business people to understand tech, and tech people to understand business-speak and bottom lines, the more you pull them away from the essential activities that make them valuable. You need a good communicator who can focus on both in the middle. It’s much easier for 3 people to run a relay marathon than 2.

Read Full Post »

My local Fox19 news had a great story this morning about Turner Medical, a company that once manufactured automotive parts but repurposed their organization to manufacture body parts. I found the brief news feature uplifting. Rather than completely giving up in the face of a plummeting economy and automotive industry, someone had a better idea.

Having just taken the Clifton Strengthsfinder 2.0 test, I couldn’t help but draw a comparison to the Strategy, Ideation, and Adaptability involved in formulating a transition like this.

Are you part of a company that has made a similar transition, or shifted focus from one area of competency to another?

Read Full Post »

“We have to set the standard, and they have to live by that.”

This was the terse email response I received from the project lead. I had asked a few questions about how we were going to design a new system which would increase the efficiency of internal work, as well as affect how, when, and how much people got paid for selling the product.  The “We” was the IT department.  “They” were collectively both the people who would execute the processes we were designing and the customer they served, the sales department.  In 14 years, I had never heard these words connected in this way.

It explained a lot. When I had been conducting interviews to gather requirements, from the desperate, overworked workforce so eager to give them, I had determined I needed to have a conversation with the sales people. When I approached the IT manager to ask about facilitating this conversation, he said “they’ll tear you apart.” Images of Hellraiser. I couldn’t communicate with the major stakeholder. And why? Who knows exactly, but evidently a “departmentally” damaged relationship, likely due to a perception, a paradigm, wherein IT people take a dictatorial approach to designing software. “We’ll tell you how you need to do something.”

So here’s the news. Salespeople, who deal with the customer directly, will always know best when it comes to how a process needs to work. From point-of-sale to product delivery, it has to come as close as possible to the square peg sliding smoothly into a square hole custom design for that peg. Like puzzle pieces, when something fits, it is undeniable, even though we may have questioned the fit before comparing the content of the pieces themselves.  But unlike a puzzle, the sales piece comes first.  The IT piece that best fits with it does more than align its grooves and slots.  The content of that IT piece not only begins to complete a picture, but enhances it and affects it’s impact upon the eventual customer who looks upon and consumes the completed picture.

Sadly, the friction in this instance represents an attitude, a perception or paradigm.  These are tough obstacles, especially if those who hold these views are particularly high on themselves (a.k.a., insecure).  These are people who believe that IT pushback on management and sales requests is a requirement.  The relationship, they think, is just not right or healthy if we don’t say “no” a few times.  Guess what?  They don’t even have the right to hold this belief.  They don’t even know what “heuristic problem solving” is.

Here’s how the conversation should sound, in a nutshell:

1) Sales person calls IT manager guy: “We need to be able to turn peanut butter into jelly. Can you do this?” asks sales person guy.
2) “Yes,” responds IT manager guy Notice the answer is “yes” and it’s immediate, without qualification, whining or long sighs.
3) “How much will it cost?” asks sales person guy. A perfectly natural question.

Here’s the step where the nature of the puzzle pieces fitting together is visible.

4) “We can do it WAY X, which will require 300 man hours and new hardware. We can do it WAY Y which will take less time, but there’s a higher cost. Then there’s WAY Z….”

The responsibility to choose how much the endeavor will cost, and how something will be done, is entirely on the originator of the request, and the person closest to the customer. The responsibility on IT is to be aware and provide an array of options, perhaps with a dash of organizationally-minded awareness (how the provided options play into what has already been established within the organization). Notice, however, this is a cooperative, collaborative interaction.  Nobody’s telling someone how to do something, or rules they have to live by, and most importantly, nobody is saying “no.”  Of course, upon making a choice, there are <i>then</i> rules to live by in order to effectuate the choice.  But the chooser has the information to make that decision.

If your organization doesn’t operate like this, the pieces aren’t fitting together, and you or your IT people are saying “No” a lot, you had best get out of your backward thinking.  Otherwise, the people hearing the “No” might just respond the same way when you ask them if they need you to come into the office tomorrow.  They’ll find the piece that fits.  Will you be part of it?

If you like backwards things, read this.

Read Full Post »

SEO Confusion, Cleared

I was hired by a great client to help him with his website, in particular, with helping direct traffic to the site. I’m not really an SEO expert, and being rather turned off by all the snake oil surrounding the subject, it’s not something I wanted to get into. But I was obviously motivated by a paying client, so I set off to gather my intelligence.

The Wikipedia entry is pretty good, but I chose to go with a technology-based book, specifically Professional Search Engine Optimization with ASP.NET. The book is great because it doesn’t claim to know everything and does a good job of providing reliable resources in the form of reliable URLs. In researching those URLs, I came upon the Microsoft SEO Toolkit, which is also a part of the Microsoft Web Platform. (Go ahead and get the Beta!) It’s as though Microsoft hired Apple people to come redesign IIS 7.0 development (is that mean?). Dozens of resources are available through this platform, and the SEO Toolkit is certainly one of the gems.

SEO Toolkit

SEO Toolkit

The reason the SEO Toolkit is so swell is because it speaks in both management and developer lingo. You sic the Site Analysis tool on your website like a hungry bulldog and it finds all sorts of violations, offers explanations, and pinpoints the code where the issues occur. For example, my client’s meta descriptions were all a million miles long, and as the Analysis tool kindly explains:

“Reduce the length of the text inside the title tag of the page. The title must be unique, descriptive, and accurate. The title must be between 5 and 65 characters long. The title should contain keywords that reflect the page content, and it should be easy to read.”

Wow. Actionable, communicable instructions and reasoning are provided. This means you can provide the same to your clients when they ask you why you spent [x] amount of hours on their website. It eliminates the snake oiliness. Further, it creates measurable results. At the beginning of the day I had 1228 violations, at the end I had 337 (due to a flawed User Control which will require a bit of work). It also forces proper coding, because the spiders can’t read your sites if you haven’t closed your tags correctly, if you have multiple h1’s on your page, or other ailments.

I haven’t even breached the Sitemap or Robot Exclusion tools, but between the book and the SEO Toolkit, I know I’m treading on solid ground in my efforts, and so does my client. This means he has no trouble paying my invoices, and that means more Rob Roys!

Read Full Post »

In Chapter 1 of Alistair Cockburn’s “Writing Effective Use Cases,” which I have to believe is the book most often recommended when someone is seeking to learn about use cases, we are first presented with a few questions, the second of which really captures the tone of the tome, and frames what I’d like to discuss today:

“Why do different project teams need different writing styles?”

First and foremost, when I read questions like this, I hear all the upper-management types I’ve dealt with in the past whine the same question: “Ok. First you convinced us that we need to document requirements, and now you’re telling us that there’s going to be some work (a.k.a., money) to determine the style that’s right for our team?” This is, of course, a cup-half-empty perspective on the idea. After all, going through a process that would result in your organization achieving greater communication and efficiency isn’t a bad thing. Documentation alone is a hard sell, especially when budgets are tight (or “in this economy,” which I believe has recently replaced “in bed” as the most popular fortune cookie ender). And you can’t use hollow, stock phrases like “all successful projects start with good requirements.” All the people holding the purse strings hear when you give them that stuff is akin to the teacher from Charlie Brown. So it’s important, as analysts, that we have a pointed reply, something beyond “We’re just going to use the force.”

Step 1 – Identify the Levels.

Thank goodness, Cockburn points out the three levels of detail in writing use cases, which is good, because management likes short lists. If you tried to say “there are ten levels of detail we can use to write use cases,” this would cause wincing and grimacing.
Effective Grimacing

I’m not saying that it’s possible to explain the effectiveness of use cases to that guy. However, what comprises the three levels is as equally important as the fact that there are three. The “brief” use case is the short, one- or two-sentence statement that can fit in a table or spreadsheet. The “casual” use case can be a few summary paragraphs, and the “fully dressed” use case is the most thorough approach.

Step 2 – Identify which to use.
So now that we have presented our short list of methods from a reputable source, we will no doubt need to respond the next obvious question, “Which style do we use?” It doesn’t hurt anyone to take all the Use Cases identified and compose the “brief” style. Obviously this gives you a nice, informative list of work items to which you can append priority, frequency of use, or other tidbits. Whether the brief use case is a candidate for a more verbose explanation via the “casual” style can come down to a couple questions:

1. Have we done this before?
2. Is this a core piece of the project? Either from
a. a development/complexity perspective or
b. the client/customer perspective

If functionality has been developed on similar projects, obviously a very minimal amount of discussion is required to reproduce the same in the new project, so going beyond the basic is probably not warranted. What immediately trumps this for me is if either the development team or certainly the customer has any concern or gives the use case any weight. The “casual” style is both perfect in name and intent. The word “casual” plays down any notion that you’re going to go into some deep analysis that requires time and money, and yet you give the use case the treatment it deserves to create the communication baseline.

Last, but certainly not least, the “fully-dressed” use case. I like to think of these as “black tie” use cases.
Black Tie Use Cases

Here, we’re really thorough and detailed and maybe even looking for a degree of polish, as we would if dressing to go to the ballet or a dinner party. This method is called for if both the client and development team consider the functionality to be core to the product. Even if the functionality has been developed before on a previous project, if it is core to the new product, a full treatment is required because the core usefulness of the feature is directly tied to the client brand. If I can’t take money out of the ATM machine, the bank name suffers. In addition, fully dressing the core functions allows the uniqueness of the particular client/customer to come to the surface. It works like salt and pepper work to enhance natural flavors. Just like with ATMs, each bank has a different flavor on the same function based, at least in part, on their branding which leaves you with the ability to favor one over the other. So, functionality that represents a point of market competition, and thus a major business objective, must be fully dressed. I also use a metric to govern whether the use case needs the full treatment, such as if three or more questions arise from any stakeholder.

So that’s a two-step procedure for selling the idea of using use case analysis for projects to those in power. Two steps! Golly jeepers that’s easy! Here’s the kicker: the discovery process happens whether realized or not. Project teams, in order to achieve their highest degree of efficiency and productivity, require a discovery process to find the methods of requirements documentation that work best. This can either be recognized or not. It’s a matter of unconscious incompetency or conscious incompetency, not knowing what you don’t know, and knowing what you don’t know. Those companies that proactively engage in the process become successful, productive, and fun places to work. Those same companies have either established analysts or analyst consultants as key contributors. These people can also effectively throttle the amount of requirements practices exposed to a particular team. The result is you either have companies who understand the complexities before the project at an appropriate level, or are reflecting on them in the same – albeit more excruciating – detail as they close their doors forever.

Read Full Post »

Is your company using a consistent practice of writing use cases? Are there a lot of power struggles between developers and team leads, between clients and product managers? Is there a lot of arguing going on? Are people nervous or disgruntled? These are symptoms of ambiguity. Create clarity.

On a recent assignment as a developer, I was part of a team creating an interactive website for a major client who serviced Fortune 500 customers. Although a requirements document was present, and the phrase “use case” was used at least once, my first experience with an actual use case came when one of the testers sent me her detailed analysis of an error she was encountering. Something along these lines:

  1. User logs in to the website
  2. The user home page is displayed
  3. User requests to view current discount information by entering dates
  4. System crashes, displaying nasty .NET error message

Of course, my obvious question was, “what should it do?” This produced a different sequence, beginning at Step 4.

4. System displays a list of discounts for which user is eligible to participate.

At this point, I asked “what has to happen in order for discounts to be there?” We established the preconditions, or eligibility. I then asked, “What is it the user wants to do once they see this list of discounts?”

“They need to enroll in the program to get the discount,” she explained.

“That sounds pretty important. Are there other tasks they perform when they get to this listing?” I asked.

“Sure. They can request the payout from receiving discounts, and they can sort and filter the list to print out the programs that are important to them.”

Voila. We had established a “View Discounts” use case, which needs to be separately broken out as its own use case because it is an action that serves as the basis for multiple tasks. We had also established “Enroll in Program”, “Request Payout”, and potentially “Print Programs List.” I say “potentially” because the ability to print lists has become a standard and technologically easy. It certainly doesn’t mean that the requirement shouldn’t be written somewhere, including the non-functional elements of how to implement the printing in the user interface.

I whipped up some basic use cases using a template from Karl Wiegers’ site. In less than an hour, the developers knew – and would continue to know – exactly what the website needed to do, without needing to meet a dozen times to clarify. Of course, we had to say “get it done as it’s written, then we’ll talk about the basket of questions or issues that may come up.” This is a production-oriented, or daily build mindset. If a ton of questions or issues come up after the use case is fully completed, then your style needs to be adjusted, or the use case needs to be accompanied with more non-functional design requirements. If the client had signed off on the use case prior, then these additions become change requests and garner the ability to charge money.

The management had an exact idea of the effort required to produce the functionality. In addition, they understood what the “use case” links in their requirements software were for, and the tasks listed in that software became pointed and relevant, because they were connected to an actual use case! It became harder for developers to drag their feet in an effort to extend their contracts. Instead of standing up in the morning and answering, “I’m working on the discount listing display,” five days in a row, the need to answer the more specific question – “what part of the discount listing display are you working on?” – became more readily apparent. If that answer isn’t changing daily, resources can be shifted.

Of course, in this scenario, this project arrived at the need for use cases and specific requirements after the product had been released to the client and errors were being encountered. This reactive position makes it difficult to manage the project and client expectations. But even in this defensive position, simply establishing some use cases throws floodlights on all aspects of the project. Developers know what to develop, testers know what they are testing, management and clients have consensus on what is being done, what gaps arise and why, and the process becomes less argumentative, more collaborative and cooperative, and ultimately productive.

Read Full Post »

Older Posts »