I spent the greater part of my evening trolling Kickstarter.com. You’ve likely heard of it and maybe you’ve even donated funds to support a project. There were a couple projects which I found quite interesting, which I wanted to share.

1. Charge your iPhone as you walk, jog, and generally as you live your life: http://www.kickstarter.com/projects/358170719/infinity-cell-kinetic-charger?ref=live

2. Spark Core: Put anything you could ever imagine online: http://www.kickstarter.com/projects/sparkdevices/spark-core-wi-fi-for-everything-arduino-compatible?ref=live

3. Space Monkey: Have your home be part of the “cloud” without being reliant on one data center in a particular area: http://www.kickstarter.com/projects/clintgc/space-monkey-taking-the-cloud-out-of-the-datacente?ref=live

What do you think of these products? Do you have any others you think are awesome and would like to share? Let me know in the comments section below!

In a survey of over 500 senior business and technology executives done by the MIT Sloan School of Management, only 18% say that their company’s IT spending was “highly aligned with business priorities.” This means that in 82% of organizations, IT is consistently spending time and money on projects that were not addressing the actual needs of the business.

As practitioners, our experience has shown that one of the reasons for this misalignment is that business and IT often have very different interests. Business wants to overload IT projects with features and expects IT to deliver quickly, while IT is much more concerned with mitigating project risk, keeping project budgets under control, and protecting themselves from being held accountable for project failure. As expected, such divergent interests often lead to friction between business and IT and lackluster project outcomes that don’t actually satisfy the business’s needs efficiently.

How can CIOs and other IT executives ensure that IT focuses only on those projects that will provide business value or address a strategic problem for the business? One way is to begin by analyzing the business problems that the project is attempting to address, and the business objectives of the project.

At Seilevel, we use a visual model called the Business Objectives Model to highlight the business problems that the project is meant to address, and the business objectives of the project. Creating this model requires extensive discussions with the project’s business and executive stakeholders to understand why the project is needed in the first place and the return on investment that the project is expected to receive. When done properly, these discussions should take the form of a dialog between IT project leaders and business stakeholders. The business help IT align the project’s objectives with the overall business strategy of the company, while IT leaders should provide feedback to the business on whether the project can reasonably be expected to meet those objectives. Rather than using the language of IT, the model should articulate the problem and objectives of the project in terms of money—fundamentally, decreasing costs and/or increasing revenue.

The business objectives of an IT project should align closely with the overall business strategy of the company. If they do not, or if the business objectives of the project are not clear in the first place, it is a good sign that the project should be canceled or retooled to align more closely with the organization’s strategy. While this may seem like common sense, it can be difficult at times to stop the momentum of a project once it gets going, especially when there is executive-level support and budget to pay for it. However, failing to perform this analysis before a project begins can lead to much higher costs later on. It can also damage the credibility of the IT organization as a whole, and create mistrust between business and IT that eliminates any hopes for generating alignment between business and IT. This type of mistrust can set up a project to fail.

As an example, when we worked on a project for a large technology company, we were faced with a hostile business executive who said, almost in so many words, that it was not IT’s job to worry about the project’s business objectives. His words were, “who are you [the product manager] to ask me about my business objectives?” However, after explaining how a lack of clear business objectives could easily result in the delivery of an unsatisfactory product, he clearly understood why the IT team needed to be a part of those discussions. The executive then agreed to work with us to define coherent business objectives, which we have used to drive the current direction of the project’s features and requirements.

We’re thinking of attending the 2013 Mind the Product conference in London this September.

Have any of our readers attended? Thoughts? Please give us some feedback in the comments section below.

Thanks!

A nice trick that business analysts can use now that collaboration technology like Google Docs exists is to allow meeting participants to simultaneously collaborate on documents during the meeting itself.  Simply have everyone in your meeting open up the document on their own computer, and then everyone can edit the document together in real time.  In spreadsheets, how this works is that whoever clicks to edit a cell locks only that cell for themselves, while every other cell in the spreadsheet can be edited by other users at the very same time.

This allows you do much more collaborative work in your meetings, and much more detailed collaborative work. Rather than relying on dictating your comments to the scribe responsible for updating the document, each participant can enter their own comments quickly and exactly as intended.  This saves time in the meeting, and also allows for more precision in the document itself.

Additionally, collaborating directly on documents allows for several different tasks to be taking place at the same time.  If one stakeholder is entering comments about one part of your document, other stakeholders can enter comments about other parts.  This prevents wasted downtime and allows stakeholders to work ahead when their topics are not being discussed.

A great use for this technology is to quickly gain a consensus on priorities. You could walk through a list of features and have a column for each stakeholder to enter their ranking of each feature. After you read off the name of the feature, wait a few seconds for everyone to enter their ranking, and then have a column that automatically averages all the rankings. Everyone can instantly see how everyone else has ranked the feature, and ask questions on the spot if they don’t understand other’s rankings. This may spur needed discussions and eliminate confusions about the feature. This method allows quick prioritization and records the input of every meeting participant, so there is no guesswork as to why a feature was prioritized the way it was. This allows everyone to have their say, no matter how many meeting participants there are. It works for small meeting just as well as for large meetings with dozens (or more!) participants. And distance is no obstacle. You could have participants all over the world editing the document as quickly as if they were in the same room as you.

A final benefit of opening your document to online collaboration is that the stakeholders can add more to the document after the meeting. If additional details or changes come to mind later, they can jump into the document and add them instantly.  Your document becomes a living document that doesn’t require repeated meetings to improve, since improvements can be made at any time day or night by all participants.

The quality and amount of collaboration your team experience varies greatly depending on the types of tools that you make available.  Simultaneous online document collaboration is a tool that you should employ as often as possible to make your team more effective through improved collaboration.

Want more tips? Check our BA online resources!

Joy Beatty and Anthony Oden discuss the top questions about managing software requirements with global teams. What skills do you need to develop in your teams? What process frameworks should you put in place? What requirement tools are available and which should you consider?

Introduction to Joy and Anthony.

Joy kicks off the Webinar by giving an overview of the concept “Being Global,” and shares an example.

This section of the Webinar covers the requirements framework that must be established for all requirements activities.

Joy initiates the conversation around building requirements skills. She discusses taking into consideration what each team member brings to the table and how to tailor the learning path for each individual in the team.

Knowing how to build requirement skills and mentoring people is important to making your projects successful. Hear Anthony cover how to educate your team with the skills.

Covering the next level of the pyramid, building a framework. In this video the team discusses building a common framework: terminology, methodology and templates.

Continuing the conversation on frameworks, hear a real life example of how frameworks benefit your projects.

The third layer of the pyramid, tools, are covered in this portion of the Webinar. Joy discusses the five types of tools that Seilevel uses during projects.

Covering the top layer of the pyramid, this portion of the Webinar talks about measuring the success of your projects and sample outcomes you should consider.

Skills, framework, tools and metrics in the perfect world are covered in this Webinar summary video.

Want to see more? Visit Seilevel’s website for additional tips and videos.

Recently, I attended a luncheon with a diverse group of people in the IT industry–coders, program managers, product managers, business analysts, and architects.  The topic of the luncheon is not important, but at one point the conversation veered towards managing a product backlog, and how to prioritize items in the backlog.  Two of the engineers in the crowd mentioned “refactoring” as an item that might go in the product backlog.

For those who don’t know, “refactoring” essentially is “cleaning up” an existing code base to enable changes to be made more efficiently, or to improve the performance of the existing system.  Refactoring usually involves restructuring or rewriting portions of code which are convoluted, difficult to understand, poorly documented, or unnecessarily complex.  “Refactoring”, the engineers argued, is often essential to add future features, so developers should be given time to “refactor” existing code–even if nothing else is in that sprint or release.

Sorry, but I have to call B.S. here.  “Refactoring”, in and of itself, adds no value, so it is not a feature, and should not be added to a product backlog.  As a product manager, how am I supposed to sell a release which includes no new functionality, but has “refactored” code? Why would anyone want to buy such an upgrade?  What does “refactoring” offer to a user?  Sure, it may offer increased performance or flexibility, but what if the user is happy with the current performance?  If it doesn’t add any business value, it isn’t worth doing.

Let me pause my rant for a moment to mention that developers who typically fight for periods of “refactoring” are typically the best developers on a team.  They can’t stand seeing inefficient, messy, unmaintainable spaghetti code. I understand and appreciate their frustrations.  There may be a secondary value to allowing “refactoring” to make it into release–to keep your developers happy, sane, and from leaving for greener pastures and that mythical software company where all code is documented meticulously and written as elegantly as possible.  Besides that purely secondary value, I argue that “refactoring” is not worth doing as its own feature for the following reasons:

1. It doesn’t accomplish a business goal:  The goal of a software company is to sell working software.  Refactoring doesn’t allow me to sell more software, unless there is something I need to add to the software that requires refactoring.
2. It obscures the “real” problem that is trying to be solved with refactoring:  I’m hesitant to devote an entire sprint/release to “refactoring”, because as a user I don’t know what problems that will solve for me.  If you tell me I can’t add the features in the next sprint because the code base is munged, then account for the time you have to “unmunge” (yes I just made up that word) the code into your estimate. Otherwise, what you’re doing is gold-plating and unnecessary to delivering value.
3. There is no traceability between “refactoring” and any discernible feature:  This is related to the above points, but if I can’t trace what you’re refactoring to a requirement, then it’s gold-plating.  There might be activities that a development team needs to take in order to fulfill a requirement or fix a defect (e.g., “improve page response time to 2 seconds”), but those activities should trace to a requirement.  You can’t predict every feature I’m going to ask for as a product manager, so you might be unnecessarily refactoring portions of the code base.
4. Your work might be thrown away tomorrow:  Suppose I relented and allowed the development team 3 months to refactor a messy code base, without adding new value/features.  the following month, the CTO decides to change the platform completely and start (mostly) from scratch, perhaps for good reasons.  Meanwhile, my users are stuck with a release that included worthless “refactored” code instead of some valuable features until the new version on the new platform is released.

I want to reiterate that I don’t think that refactoring should never be done, but that it should never be done in a vacuum, without any relationship to business value, solving a business problem, or satisfying a requirement.  Hopefully, there can be fewer conversations about refactoring and more conversations about how developers need time to perform some housekeeping in order to satisfy a requirement.

I am currently knee deep in a project to configure data mappings for healthcare ETL processes. Although there are standard formats for every exchange of healthcare information, the new core system needs some TLC to make all of the data flow correctly into and out of the system.

The best tip for managing successful data mapping is to prioritize the data first. The business stakeholders can certainly tell you which data is more critical than others. In industries with well defined data structures, this can be as simple as showing all of the data available and asking your stakeholders to rank each element (or groups of elements) with the MoSCoW rankings.

Your stakeholders may be over zealous in their rankings. That’s ok. Not everything can be a “must have” element. With a little business analysis, you can shed some light on discovering the true rankings for data. Examine the workarounds for getting the data if it isn’t mapped. How much time would it take? What would this cost?

As an example, consider a healthcare claim. There are thousands of individual data elements on a healthcare claim, but chances are your health insurance company doesn’t use each data element to adjudicate the claim. The claim data that does not impact adjudication can be ranked “could have” at best. Of the data that does impact adjudication, consider which elements take the most time to get. If the member name is missing, a claims analyst would have to call the provider who submitting the claim to find out who the member was. If this data was unmapped, they would have to call each provider and ask about each claim. This would take more hours than are available in the day. Clearly the member data, along with several others, are “must have” elements.

Data that isn’t necessary for the delivery of the product, but is still useful in other ways, is ranked “should have”. Continuing the healthcare claim example, any data that does not impact adjudication could be in this category. The company may use this data internally to analyze trends. For example, the ethnicity of a member doesn’t affect adjudication (the product that the healthcare company is offering), but it does assist in setting premium rates for members.

Once you have a sense of your data rankings, you can begin mapping. Start with your “must have” elements. After thorough testing, the business may consider going live with the mapping. After all, time is money. It could be wasteful for the “must have” data to be held hostage by the unmapped “could have” data.

By this point, the agile methodology is recognizable. Continuing with a release that addresses the “should have” data enhances the product that is already operating to address the core needs of the business. Finally, adding in the “could have” data in a subsequent releases accelerates the product for future functionality. All of these planned releases avoid the time and cost of defining, mapping, implementing, testing and releasing unneeded data.

We have had a lot of discussions internally about “Measuring Project Success.”  At an extremely simplistic level, Seilevel defines success as having been achieved when all the business objectives identified for the project are met. Each business objective will have one or more success metric(s) defined for it. So, when we are able to measure and evaluate each of the success metrics identified at the beginning of the project, we will have an objective measure of project success.

As we work through this process of defining project success at Seilevel, one thing stands out to me. There is no universal or “standard” way of measuring the success of an IT project. In fact, there are probably as many definitions of success as there are organizations implementing IT projects.

Below are some examples of project success statements that you may have heard before.

1. We met our business objectives. Successful project!!
2. We measured all the success metrics for each of our business objectives. All measures came in at or above our targets. Successful project!!
3. We solved the business problems we were addressing with our efforts. Successful project!!
4. We came out of testing and launched over the weekend. It has been five days since launch and no one has been fired as yet. Yay, we made it!  Successful project!!
5. The entire sales team has been using it for a week and we have not heard anything. So must be working out well, I guess. Successful project!!
6. We just finished our “Lessons Learned” meeting this morning. With that, we have hit all our project phase exit milestones. Time to move on to the next big thing. Successful project!!
7. You mean the stuff we worked on last summer? I have since worked on three new initiatives and moved on with life. Successful project!!
8. Are you trying to get me fired? I am not going to measure anything. Please leave my office immediately. Successful project!!
9. The whole team got fired. It was a disaster. This is what happens when you start measuring stuff randomly. Successful measurement.  Disastrous outcome!!
10. Did we spend all the money you had budgeted for the sales process improvement project last year? Yes? Excellent. Successful project!!

Your own organization is likely using one or more of these ‘qualifying statements’ or some variant thereof to measure project success. I would also guess there is no agreement even within the different teams in your company as to how to measure success or even bother with it.

So why does any of this matter? We have all been chugging along quite well so far without having to be held accountable for our actions in any meaningful sense so far. Why mess with a good thing?

Three reasons come to mind right off the bat to change the status quo of non-standard measures of success (for that matter, an outright indifference to even attempt to measure it in any meaningful fashion). None of these reasons are altruistic, and extremely meaningful to anyone who practices our craft or is considering it at profession.

1. Unless we can agree on some reasonable definition of project success, we can never really advance our profession in any consistent manner. If anything we do can be deemed a success or failure in some arbitrary fashion, then we are all on very dangerous ground.
2. We have no way of truly articulating the value we provide to our organizations. Unless we are perceived as practitioners of a well considered craft implementing a repeatable methodology that can deliver measurable success, we are all just glorified note takers with above-average Microsoft Office skills. This again is a very dangerous position to be in.
3. It is flat out nuts not to measure project success consistently across our organizations. Imagine for a moment if the Medical profession were organized like we are. Every doctor would be able to declare victory regardless of whether their patients actually felt better or not.  Worse yet, any patient would be free to call any doctor a quack and make it stick because they could just arbitrarily define “cured” as it related to their medical condition. We would all be outraged and demand that something be done to fix this affront to common sense immediately. Yet we have no qualms about accepting it in our own line of work quite cheerfully.

In subsequent posts, I will explore the reasons why we find ourselves in this predicament and what we can do to get out of this mess.

What is your experience measuring project success? Tell us in the comment section below, then check out some of Seilevel’s successes.

For business analysts, a Process Flow is one of the most straight-forward models to interpret: Process Step 1 is related to Process Step 2, relating to Decision 3, which leads to either Process Step 4 or Process Step 5. Not much mystery there, right? While the flow may be easy to follow for you, there is nothing easy about structuring these flows in a way that is simple for other people to understand.
Let’s just say you have spent an hour with a subject matter expert (SME) going through all of the ins and outs of a process you want to model. You took great notes on all of the various details and have painstakingly translated each process step into its associated box, each decision into a lovely decision diamond, one connecting to the other until you have a complete model with 30 objects, boasting end-to-end coverage of the entire process. Everything seems to be right with the world, until you sit down with your SME to review your work of art and they can’t make heads or tails of the process you are describing. To them, your Process Flow looks more like a Jackson Pollock painting than the process they spent an hour describing to you. The verdict: unreviewable!

To keep this from happening to your Process Flow, keep it simple! Any given Process Flow should have approximately 7 steps (plus or minus 2); meaning, the overall amount of process steps and decisions should be limited to between 5 and 9 steps. This way, you can start out reviewing a generalized version of a process in the first level of the flow (L1) and dive into the details of a step in a separate level two (L2) Process Flow. Each L2 process step could even have its own level three (L3) process flow related to it, if necessary.  You can go down the rabbit hole as far as you want, but it makes the most sense to stop at the level of detail necessary to start pulling out your functional requirements. As we saw above, there is such a thing as too much detail!

While the L1, L2, L3 Process Flow structure sounds obvious enough, in practice, this can be really tricky to build. After struggling with this myself, I was given the following sage advice that I found really helpful: Imagine each process step as a person doing a job.

Let’s say, for example, we want to model the process a magic shop goes through to price a pair of wacky X-Ray Glasses (Hey, at least it isn’t another example based on a retail website, right?) First, we need to understand the cost associated with making these glasses (Production Costs). They aren’t selling these X-Ray specs for charity, so they can’t charge less than it costs to make the glasses. Next, they need to understand what your average-Joe magician might be willing to pay for the pleasure of seeing through walls (Demand). Are there comparable X-Ray Glasses selling elsewhere? How much demand is out there for goofy glasses? Finally, the magic shop needs to be able to determine how many pairs are currently collecting dust in the storeroom (Available Stock). If they have a bunch lying around, they had better be priced to move.

So, based on the above scenario, it is clear that the magic shop has a variety of questions associated with each aspect of the pricing process. Instead of attempting to capture every aspect of the process in a single flow, imagine each step (Production Costs, Demand, and Available Stock) as a person. Start out by imagining each step of the above three step pricing process as a person doing a specific task.

As you build your L1 flow, imagine yourself going to each person and asking for pricing information: Siegfried knows the production costs, Roy knows the amount of customer demand that’s out there, and Harry H. knows how many X-Ray Glasses are sitting around in the stockroom. This would represent your L1 process flow.

To get to the L2 process flow, imagine yourself asking Siegfried how he arrived at the production cost? He might say, “Well, the mini vacuum tubes cost 300K, the tungsten anode costs 46k, glasses frames cost 10 cents. Add them all up and you have X-Ray Glasses.” This information would constitute your L2 process flow.   If there are sub processes within the L2 flow, model them in a L3 flow, and so on, until you have a series of models that has enough detail to identify requirements.

When the time comes to sit down and review these flows and the associated requirements derived from the flows, it will be easy to step through the overall L1 flow first, and then visit each step in greater detail, using the L2 flows. Trust me; your stakeholders will thank you for not having to rely on their X-Ray Glasses to interpret your Process Flow.

Want more requirements development techniques? Check out Seilevel’s comprehensive list of business analysis tools online.

Karl Wiegers and I are chipping away at Software Requirements, 3E, and well over 1/2 way done! He wrote a blog post for the Microsoft Press blog about our writing and collaboration process. He describes a bit about our decision to undertake the writing effort and how it works when we live far apart in Oregon and Texas. An interesting thing if you are going to co-author – make sure you have some confidence you will be able to collaborate successfully! Simply knowing you have interest and knowledge in the same topic isn’t sufficient. You need to explore enough to ensure things like:

• your writing goals align
• your ideas align
• you have a collaboration process that works for both of you
• you are both equally committed to the project (or agree on who will do the bulk of the work if not equal)
• and…you get along, so you can enjoy the project – because you will spend a lot of time on it

In the spirit of a good BA, Karl developed a swimlane diagram for our writing and collaboration process! Check out his post on much more about co-authoring Software Requriements, 3E.