Posts Tagged ‘project’

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’m in the process of getting through the PMP Exam Cram. I did this as I venture deeper into a career which is focused on helping companies achieve greater success with their IT projects. My approach started with a focus on more of the BA side of things – requirements elicitation, use case composition, overall requirements process structures, etc. I was interested in understanding the PM role and I found some interesting overlaps.

A lot of the BA and PM material I read seems self-aggrandizing. Does anyone else get this sense? It’s as if the authors are selling the value of the position to the very people who have already been sold on it. In this instance, as well as the IIBA’s BABOK, I’d say a good 20% of the material is “which is why your role as a [BA/PM] is so important.”

I’m guessing one way of really understanding how the roles overlap is by asking, have you ever been in a situation where your role as a BA or PM has conflicted with someone else in the opposite position? Or have you seen such conflicts?

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 »

“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 »

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 »

Information Technology has reached the finish line. You can’t write code that hasn’t been written before. You can’t develop software that I can’t buy. The focus of IT on social networking results in nothing more than the same advertising sales that brought Yahoo! to stock market prominence, eventually becoming Google’s dominance, but is predicated entirely on our need to see an advertisement in order to consume a good or service. Great! Now we can all talk to each other, and we don’t have to use the phonebook, or even a phone.

What is IT able to do to now to actually further global progress? DNA analysis? And how many job slots are available for that purpose? Has IT reached a massive finish line and is that why so many of us are seeking opportunities now? What does the world need now?

Let me know. In the middle of this gloomy economy (and a matching weather pattern in Cincinnati at least), are you actually working on something NEW?

Read Full Post »

Audio version available here: http://www.youtube.com/watch?v=SW5fx1miurc

First, a Big Thanks to all my new followers and readers. “How low can you go?” hit 200 views in 2 days and, frankly, I had expected 200 views for my entire blog for the entire month. Big thanks to the general WordPress blog community as well.

People often ask me what the correlation is between my incomplete Jazz Music degree from the University of Cincinnati and my involvement in information technology. I like to point out that Palo Alto Research Center (Xerox) veterans included Dr. Mark Weiser, the first drummer to ever appear live on the Internet with his band “Severe Tire Damage” and Rich Gold, an electronic music composer, performance artist, and cartoonist with a degree in electronic music. I also like to recall my attendance at the Microsoft Tech-Ed in New Orleans in 2002, where they set up a local pub with music equipment we could all jam to during the evenings after marathon PowerPoint presentations. Sadly this resulted in a lot of equally marathon-like performances of “Sweet Home Alabama.”

(As you continue reading, hit the play button on this performance I did with my trio at the Cincinnati Art Museum a while back. I was on two days without sleep and had just travelled from my client in Dayton straight to the gig. Sorry for the poor audio quality.)

Let Go

Phil DeGreg was my teacher during my time at UC. One important aspect I learned about jazz solos was the ability to let go of things that had already come out of my fingers. During a live performance, when you hit a note, it’s gone, history, done. The note, right or wrong, has hit the ears of the listener and they’re making their little judgment calls and deciding whether to purchase another beverage or not. Coding a software program is nearly the same, except you can delete and replace stuff. But sometimes we shouldn’t. There are a billion things I could play over a single chord change, and as well a billion ways I could create a solution in code. If I spend my time letting my mind wander to the alternatives, it makes for music that never gets heard, and code that never gets released.

It makes me wonder about Microsoft’s “release-and-service-pack” philosophy. Perhaps it is the necessarily human approach to assume that software, like music, is produced by humans, and the audience is therefore obligated to expect shortcomings, or as we say in the music realm, clunkers. The idea is to get the product out there without regret, but with the expectation that next time around, things will be better. When I play a new piece, I almost need to mess up. Mistakes are really the borders of perfection. Microsoft’s versions of .NET have certainly gotten better with each release. Although some can argue the merit of Microsoft products overall, one can’t help but feel we’re always witnessing a company growing, however painfully. I’ve certainly messed up coding plenty, but production of those mistakes practically burns the corrections into my brain like a cattle branding iron.

Practice makes…

Practicing various scales, licks, riffs, or other melodic passages affords me the ability to increase fluidity of creative signals between my brain and my hands. In effect, I’m no longer “playing” as much as I’m really “singing via the piano.” This is why I think company-mandated, on-the-job learning is a good idea. If you’re afforded the opportunity to research and experiment with new development techniques, get into some walkthroughs, branch out into other languages while in the work setting, you’re going to increase that creative fluidity while on an actual project problem in the work setting. I think being in the work setting while doing the learning creates a subconscious familiarity with innovative thought, transferable as the practice of a scale is to the performance stage.

Music and IT have a high degree of correlation and I could slice off aspects all day for you. Maybe I’ll turn this “Jazz Solos & Nerdy Code” into some sort of series. But for today, my thought is that your window of time to production is likely smaller than it was yesterday. For that reason, what you’re attempting to produce might need to become smaller as well, and the time devoted to finding the “right code” even smaller. Imagine if coding were a live performance of a jazz solo. No backspace, no CTRL+X, no regrets. Maybe an impossible standard, but oh, what a guideline!

Read Full Post »

Older Posts »