From start to end

Making change requests tangible - the home reno

The cost of change requests are sometimes difficult for a client to visualize. This is especially true with software development projects. There is just nothing tangible a client can wrap their mind around. 200 lines of C+? 400 lines? What's the difference?

To make the impact of a change request more tangible, I suggest using an example most of us can relate to - home renovations. Last fall, I had a series of basement renovations performed. One component was to add a partial wall to split an area of a room off (notice the wall on left.)

After the installation of the initial studs and drywall, I decided the wall should be a little longer. This would provide me with the option of putting larger pieces of furniture on the other side (e.g., more shelves.) The contractor had to use more materials and time to extend the unfinished wall.

Had I realized my requirement for a longer dividing wall earlier, it may have saved my contractor some time (because I caught this early I didn't waste any materials.)

Now that the renovation is complete you can't even tell the wall was extended. I got what I wanted even though it took a little more time.

For arguments sake, suppose I figured out I needed the wall extended after all the painting, floors and baseboards had been installed. Considerably more time and material cost would have been incurred. Why?

If my contractor needed to remove flooring, drywall and repaint - I would have wasted a lot of materials. Some of the flooring and baseboards would have been thrown out, additional paint and priming time would have been required, etc... All of this costs money.

On a side note, the wife of a friend of mine was also performing a renovation - the kitchen. She decided to replace the marble tile pattern she had picked for the backsplash. She made this decision after the tiles had been bonded to the walls, grouted and treated (so oil wouldn't damage them.) My friend literally cried... he understood the impact.

The moral of the story - the earlier you can identify the need for a change the less costly it will be.

Avoiding inertia and estimating how long it will take to write requirements

Back in 2007, I decided to take a couple of months off from writing on this blog. A few months stretched into a few years really easily. Once a habit is broken, it's very easy to give into inertia. I guess this is why one should aspire to never miss a workout.

Recently, I received an email from Georgia on one of my posts in which she asks, "..., I was wondering if you have any tips on how to estimate how long it will take to write requirements for a project you've been assigned to. The project is new, you know nothing about the business, how can you provide an estimate? Should you just give a high-level estimate and then adjust as you go along and see the progress?"

Why do businesses execute projects? To improve how things work, to meet regulatory and compliance requirements, to capitalize on new opportunities or avoid potential threats.

At some points in your career you'll be asked to work on projects where you have little to no expertise. Don't be discouraged however, this is how we learn. What approach should you use to estimate how long it will take you to write requirements? Here are some thoughts:

Decompose the project into the key basic business processes which will be impacted (e.g., billing, order entry, inventory reconciliation, campaign deployment, etc...)
Create a matrix using the business processes versus the different stakeholders involved - such as finance, marketing, customer service, warehousing, etc...
Indicate which teams are involved in which processes and which team is the ultimate owner of each process (who do you go to if you need a decision.) The more teams involved, the more potential stakeholder complexity.
For each process indicate how complex you feel it is. If you don't know much about the process, rely on the stakeholders and management for guidance.
Using the information you've gathered determine which processes have high, medium or low levels of complexity. As a rule of thumb you could say high = 10 days, medium = 5 days and low = 3 days.
Add up the total number of days and this will provide a really rough estimate.

Understand this is merely a high-level estimate and as further analysis is performed the estimate will become more precise. This is project estimation after all. At the start, you might provide an estimate with 100% contingency, however as the project starts to execute the level of contingency drops as more things become known.

One side benefit of using the matrix is it will also help you plan out your requirements gathering sessions (you know exactly who needs to be involved for each process.) Use this to secure participation from those teams and your project's sponsors.

Random thoughts on being service-oriented

Currently, I work in a support group in the IT department of my company. Our group assists other IT teams by scheduling, assessing impact and coordinating deployments to our production systems. In essence, these are the services we provide. For the purposes of this posting, this is my frame of reference when I say service-oriented.
Random thoughts on improving your customers' experience:

Think about things from the perspective of your customers. Perspective is everything after all.
Take your own medicine - go through the process yourself. Have you ever come across a user interface where you wondered, "What were they (the developers) thinking?!"
Don't be a cold heartless bureaucrat. It's important to your customer; make sure they know it's important to you.
Do things which provide benefit and value, not because you're following a checklist.
The process you steward can be a part of a much larger one. Never forget it. When someone asks for help but it's in another area, make sure you explain to them how the larger process works and your piece in it.
When you need to pass a client onto another service team, do it personally if possible. Make sure the transition goes smoothly.
Acknowledge the requests you've received and set expectations for completion.
Provide updates when you're running late and won't be able to meet the expectation.
Follow-up afterwards and ask for feedback.
People shouldn't use your services because they have to. Don't tell them that. People should use your services because they want to! Be ready to market the benefits in a tangible way.

Webinar: Trace requirements to business intent

Compuware is providing a webinar on July 26 @ 2:00pm EDT. You can register following this link.

Practical techniques: Trace operational and other non-functional requirements to business intent
More and more there is increased pressure to develop applications that are closely tuned to business processes and yet can be changed on a moment’s notice to reflect new priorities.

Achieving balance between business goals and the associated operational requirements set has been a challenge. Too often different stakeholders are defining the business (domain experts) and operational (technical experts) perspectives. This can lead to disconnects in the systems delivered, requiring expensive rework either late in the development cycle or in post-production maintenance releases.

WIIFM - What's In It For Me

I remember sitting through some of my directors' presentations listening to them talk about, What's In It For Me, or WIIFM for short (not to be confused with the Nintendo Wii - which I play but suck at.) The basic idea was while you worked hard on projects you were also learning, developing new skills and getting new experiences. WIIFM for everyone!

In a few of my blog posts I've written about how important it is to adjust your presentation and communication to your audience. In effect, you were telling them, What's In It For Them. It's all about creating a relevant experience to sell an idea, product or concept.

Now let's step back and examine this WIIFM concept applied to another situation. Have you ever worked on a project where you have an idea on how more success can be achieved if the project team were to work more collaboratively with other project teams and personnel? In my experience the typical project manager response is, "It's not my problem," or, "It's outside of my scope," or, "It's someone else's problem." Then you step back and watch the car crash in slow motion; the problem manifests itself and severely impact the project and company as a whole.

I liken this to Adam Smith's (the Father of Economics) "invisible hand."

As every individual, therefore, endeavors as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labors to render the annual value of society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By referring the support of domestic to that of foreign industry, he intends only his
own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention. Nor is it always the worse for the society that it was no part of it. By pursuing his own interest he frequently promotes that of society more effectually than when he really intends to promote it. I have never known much good done by those who affected to trade for the public good. It is an affectation, indeed, not very common among merchants, and very few words need be employed in dissuading them from it. (Adam Smith, The Wealth of Nations)

Basically, this means each individual acting in his (or her) own self-interest will lead to a better outcome for the society as a whole; or WIIFM but on a project-scale. The problem with this is simple. No one ever builds roads and the infrastructure to connect things because it's in no specific person's best self-interest; but that's not my problem. Is it?

I'm not saying expand a project's scope, merely understand how a project fits in with the big picture.

Someone else's shoes

Continuing from my last post, spending a day in another person's shoes will give you an appreciation and understanding of their point of view.
Try this simple exercise - Drop any preconceptions or notions you may have and pretend you are in the position of one of your clients or end-users. Do a little role-playing to increase your empathy.

What would you want or need to be successful?
Why would you want it? What would you do with it? What's the value?
When would you need it?

By no means do I suggest you use this technique to gather requirements for a client, however, it will help you look at things differently and with a more open mind.

Change your perspective

Perspective influences how you view the world. It allows you to see things in a different light than another person, but it can also keep you from understanding their point of view. When you are gathering requirements from a client, having empathy enhances your ability to understand their needs.

Benefits of being able to view things differently:

Allows you to be open-minded, receptive and patient.

You learn to think like your client. In some of my engagements, I found my clients could not articulate exactly what they wanted. I needed to perform a lot of facilitation to help gather and define requirements. Being able to think like them allowed me to probe more effectively and determine the underlying objectives.

Because you understand your client's point of view, you can anticipate their next question. This is an excellent value-add to your ability to provide service.

Changing perspective isn't a foreign concept. If you have ever created user stories, you have in essence used an approach that incorporates the different perspectives of the people involved. User stories are easy for the different parties to understand -- clear communication is always the goal.

Make understanding your client's perspective a part of every engagement.

Webinar: Getting the Right People on the Right Projects

Getting the Right People on the Right Projects (Wednesday April 18, 2007 @ 2:00PM EST)

Completing projects isn't enough anymore. The real challenge is building applications that are on target, on deadline, and on budget, to save your company money and provide a competitive edge. Therefore, ensuring you've got the right people on the right projects at the right time is more important than ever. That means effective project management.

Slew of webinars and resources

Why requirements definition is a critical first step (April 18, 2007 @ 1:00pm EST)

Managing your requirements is only half the battle. For management to be truly effective, taking the first step of defining complete, accurate requirements is absolutely critical. In this webcast, Forrester Senior Analyst Carey Schwaber will explain how you can build agreement around requirements right from the start, so there are no uncertainties down the road.

Aligning Business and IT (on demand)

Many CIOs are struggling in their quest of aligning IT with the corporate business strategies, objectives, metrics and culture. CIOs need to become more involved in the development of strategic initiatives and build an understanding of the corporate and line of business missions and goals if they seek to align IT with the corporate directions. Moreover, CIOs need to interpret that knowledge into a flexible IT strategy if the alignment is to succeed long-term.

Business Intelligence Trends (podcast)

As business intelligence (BI) evolves, new trends emerge. But whichimportant BI trends should you pay attention to? And how should yourorganization incorporate this information into BI strategies?

Webinar: Bits and bites

BPM: Aligning People, Process & Technology
Monday March 26 @ 12:00pm (EST)

Join Paul Harmon, Executive Editor, BPTrends and Principal, BPTrends Associates and Roger Burlton, Founder, Process Renewal Group and Principal, BPTrends Associates, for an insightful and lively discussion about the advantages of aligning your people, processes and technology to achieve improved enterprise performance.