If posed with this question, leaders of most organizations will put their own companies into the minority camp that actually measure project success. And in a vast majority of cases, they would be wrong. As I pointed out in a prior post on this topic, there are unfortunately as many ways of measuring success as there are projects being delivered. The lack of a standard way of measuring success results in most organizations not focusing on the one thing that truly matters – “Did the software deliver the targeted dollar returns by way of cost savings and / or revenue increases that were initially planned for?” This is the Seilevel definition of success for commercial software implementation, and one that we are urging the industry to standardize on.

Measuring project success is not the same as evaluating the success or failure of development and delivery of a given piece of software with a set of features. If the software is never delivered or very poorly adopted, then we have an automatic and default measurement – failure. In these cases, it really does not matter whether the organization explicitly measures project success because we know that none of the financial goals will be met by software that never saw the light of day or is barely used. Failed projects are analyzed and either abandoned because they never made business sense to begin with or resurrected for redevelopment. The problem of measuring success then ironically lies with the projects that are actually delivered, deployed and in wide use! By default, we have defined success as the “absence of failure.”

So why then do most organizations not measure true project success – the economic value delivered by the software? Here are the top six reasons based on my observations of working on many large implementations.

1. Lack of Understanding  the Importance of Measurement
The use of the default measure of success – “not a failure” – is largely the result of lack of understanding and a false assumption. The belief is that, if a project is actually delivered and used, by extension, it must have delivered the desired financial returns. This is a dangerous assumption to make and one that is impossible to validate unless measurements are actually made.

2. Lack of Understanding What to Measure
This goes directly to the heart of the problem – most organizations do not use the financial returns generated from a software deployment as the only valid measure of project success. Without this knowledge, most measurements if they are made, do not truly measure success.

3. Lack of Understanding How to Measure
This is a non-trivial problem even for organizations that measure project success by attempting to nail down the financial returns to the business as a result of a software development exercise. Ascribing causality to software, especially when it comes to measured revenue that is impacted by a wide range of external and internal factors, is not easy to do. In a lot of cases the means to measure performance have to be developed before a measurement can even be taken. For example, if a financial target of reducing support costs by $100,000 is predicated on 5,000 problems being solved by an online interactive knowledge base, we must first be able to measure how many problems are actually solved using the online tool in addition to the actual dollars saved. If there is no way to measure the number of problems solved online, it has to be developed in conjunction with the original feature or after the fact to permit measurements and readings to be possible.

4. Not Part of the Development Process
Most good Development Processes I have seen start with some kind of justification for a feature or application – typically in the form of a Cost Benefit Analysis or, if they are using Seilevel Methodology, a Business Objectives Model – and culminate with a Lessons Learned Exercise for future improvement once the software has been delivered and deployed. There is NO formal process step for measuring success at any time after the delivery is completed. Unless success measurement gets baked into the actual business processes around delivering software, they will almost certainly never get done.

5. No Budgets for Success Measurement
In Corporate America, it is not possible to even buy a pencil unless a budget exists for the purpose, the needed funds have been requested and approved, and made available to be spent. In my experience, I have never seen any formal budgets set aside for success measurements. Project Managers will include the personnel needed and an estimate of the time they will spend on a Lessons Learned or Formal Sign Off process step when they create their project plans and budget estimates. There will however never be a budget request in terms of manpower and time needed for project success measurements. If no one is paying for it, trust me, it will never get done.

6. No Person or Team is Responsible for Measuring Success
I do not believe that success measurement is the responsibility of any person, department, or team in either the IT or Business groups of most organizations. It is entirely possible that both IT and Business measure success in their own unique ways once software has been delivered, but it is never done holistically. Unless these measures of success are defined at the beginning of a project and measured systematically at a later time, no meaningful and actionable information will be available to either team once a project is complete. If no specific person or team in an organization is tasked with measurement, it simply will not get done.

The bottom line is that success measurements do not get done because we have a systemic failure. First, most organizations are unaware of the importance of measurement, do not know what to measure or how to measure it. This lack of understanding is clearly manifested in their organizational structure and budgetary actions – no one is responsible for measuring project success or, assuming that there is someone who wants to do it, there is no money to perform the measurements.

Organizations throughout the world spend billions of dollars a year on development projects. Yet no one can tell us if they really got their money’s worth. Is it just me, or is that crazy?

Six Reasons Organizations Don’t Really Measure Project Success is a post from: http://requirements.seilevel.com/blog

During a recent stand-up with a colleague, I mentioned that I was growing concerned with our stakeholder’s ever-expanding list of issues and scope creep. Each day we met to review, more problems were uncovered. My more experienced colleague shrugged her shoulders and said “Mo’ meetings, mo’ problems.” Of course, I laughed at the phrase, but it really caught my attention. All projects begin with an outline of work that needs to be accomplished. The work typically represents one to a few problems the company struggles with. Project scope is based on the known problems and amount of work required to solve them. When you begin wading through the possible solutions, and present your findings to stakeholders, don’t be surprised if an “ah-ha!” moment interrupts the review process. Taking apart issues presented during the meeting may just open a can of worms that your stakeholder will want to address then and there. So, how do you manage these moments and discussions?

1. Keep an Issues List.

Note-taking during meetings is beneficial for many reasons, including documenting issues as they arise. Your meeting minutes may contain action items, but what about items that cannot be acted on without being addressed further? Document these separately, and discuss with appropriate team members immediately. You may find that in order to implement the solutions you have proposed, another business problem must first be solved. I must note here the beauty of the agile methodology. Using short sprints in your project will allow time to address any new issues, instead of glossing over them and pushing forward to a product concept.

2. Address critical risks as they arise.

By “arise,” by no means am I referring to mid-meeting. Do not try to create the immediate “solution,” take a little time to chew on the information you received. Speak with the appropriate people. Do not lead your stakeholder to believe that you can solve every problem within the company during your allotted time. Be honest and transparent. Not only will you gain the stakeholder’s trust, you will also save yourself from possible project failure by recognizing pitfalls on the path to your solution. You may also bring in important points of contact for the project who were not mentioned during project kickoff. Let your stakeholder know what the risks are, and discuss how they may be mitigated.

3. Be proactive.

“Wait a second, did I just hear another possible project idea?”

Turn those issues into a project proposal.

“I understand that we are uncovering more issues that must be addressed. Although these do not fit within the scope of our current project, here are a few ideas I have that may be addressed in a separate project.”  And remember, not all problems have to be problems for you! Manage these issues and address them in an appropriate and timely manner.

How do you and your team deal with growing scope?

Mo’ Meetings, Mo’ Problems: 3 Ways to Manage Project Scope is a post from: http://requirements.seilevel.com/blog

My film-student daughter is currently working on her fourth movie gig – an indie zombie movie being shot here in Austin. While I admit to really not getting the whole zombie thing, I’m excited that she’s getting so many opportunities to do the work she loves. This time around she is the Production Designer/Art Director. When she started, I wasn’t sure what that would entail, but now that she’s in the midst of the work, I realize that she’s essentially a business analyst. Don’t believe me? Read on….

Project Kick-off:  Before the first meeting with her director (project sponsor) she read through the script and made a list of scenes and locations that she would need to design. Then she met with the director, reviewed this list with him, and ensured that she understood his expectations, budget, and timeframe.

Elicitation:  Next, she met with the other crew members to discover what their requirements were for props and visual design. She also went to the location where filming is to occur to make photographs and measurements and identify what furniture and decorations were already available.

Stakeholder Management & Communication:  She identified that there were some gaps on the crew to perform key tasks, so she found some fellow students who were willing and able to work for free. She identified which ones were reliable and responsive, and is managing those relationships for the director so that he doesn’t have to worry about it.

Requirements Documentation:  Based on what she discovered during elicitation, she planned the decoration of each set and made lists of items that would need to be created by the art team or procured. She estimated the cost of the materials required.

Requirements Validation:  She had the director and other crew members review and approve her plans.

Requirements Management:  As planning for the actual filming continues, there are changes to some sets and locations which she has to accommodate. Right up until filming is complete, she will have to adjust on the fly and still remain within the budget and deliver set designs on time so as not to delay filming.

So…if you think that being a business analyst is all about software, think again. Business analysis skills are applicable to every industry and creative endeavor. Even zombies!

Everybody Loves Zombies! is a post from: http://requirements.seilevel.com/blog

As an RA, I have to solve problems by searching through background documents and listening to stakeholders. Every day I am in charge of creating models that help create a successful project. One of the models that we use at Seilevel is the Business Objectives Model, to understand what our client’s business problems are and what should be their objectives. In order to obtain a good business objective model, one needs to obtain good success metrics.

Now completely immersed with this new approach to problem-solving, for better or worse, I have started using success metrics in my personal life. An example of this happened a few weeks ago when my girlfriend and I were discussing which activity we should do on a Saturday afternoon. She wanted to walk around a farmers market while I wanted to watch a movie. She was very keen on going to the market but there was a movie that I wanted to really see.

In order to win this argument, I decided to start asking questions in order to come up with a common interest that we both shared. The interest that we came up with is that both of us had a race the next day that we wanted to run well in. In order to run well, we both determined that resting would be the best idea. I told her that the best way to measure rest is by doing the least amount of movement; she reluctantly agreed. Therefore I concluded that going to the movie theater would be the best solution to our problem because we would make the least number of steps there versus at a farmer’s market.

In order to solve a problem, the best course is to first establish a common interest with your stakeholder (a.k.a. my girlfriend in this story), and define a success metric that validates a specific business objective which all given solutions can then be weighted against.

How to Win an Argument with your Girlfriend is a post from: http://requirements.seilevel.com/blog

In an episode of “The Big Bang Theory”, Leonard arrives home with his arms full of food and says “I hope you’re hungry” to which Sheldon responds “Interesting. A friendly sentiment in this country, cruel taunt in the Sudan. It’s a lesson in context.”  The humor may be dark, but the point is one we need to remember—context matters.

A group of us were at the end of a very productive, but very intense, all day session on the business rules for a third party system.  The Business Analyst switched topics and started telling us about a report that would be provided by the system.  While I understood he was talking about a report, I couldn’t make any sense of the details he was giving me because I didn’t know when the report was used or what it was used for.  I had to ask him to stop and provide context.  It turned out everyone else in the room was as confused as I was.  It was a good reminder to set context when providing information.

This applies not only when presenting information to a group, but also to work products. This can be as simple as giving a document a name which indicates its content, the small effort of adding an introduction section to a document, or as extensive as creating a vision and scope document for a large project. Requirements models are great for providing context and pulling together diverse information as well.

Context—it’s one of those things that makes the difference between providing good information and providing excellent information.

Business Analyst Tip: Context Matters is a post from: http://requirements.seilevel.com/blog

I truly love my Nest thermostat. I had a thermostat that was supposed to be internet connected, however, it never worked. It was associated with a static IP address and I always had to flip the breaker to get it to work. I was once in Chicago, wanted to turn my A/C on to a comfortable level so that when I got home my home would be nice and cool and I could get to bed. Unfortunately, that was also a day when my thermostat at the time decided that it didn’t want to be accessed through its IP address. (Yes, inanimate objects can make these types of conscious decisions!)

Then came the Nest thermostat. I got it as a gift from my family and I installed it immediately when I got home. The installation was a breeze! I’m not an electrical engineer but I was able to label the wires and put them in the right spots for this new thermostat and finish my installation in 20 minutes (time included to remove the old thermostat from the wall).  The best thing about this thermostat is that it does what it states it should: online management. A big part of the Nest marketing is helping residents cut their electrical bill by having better heat and A/C management. Although I don’t really see that side, I love that I can control it at will through my iPhone, it learns my habits, and the wall system itself is intuitive and easy to use. No more all sorts of buttons and directions that no one can follow in order to program your thermostat. After a month or so of using it, I started raving about it to my friends and family. (By the way, neither I or Seilevel is paid to review this product.)

All Product Managers want to develop products that have a cult-like following. The challenge with Nest will be how they figure out how to get a continuous stream of revenue. Apple does it through updating software which forces people to buy the new phone with the upgraded components. Will Nest do the same? My thermostat works and all I need it to do is manage my home’s temperature. What feature could they develop which would make me want to update the software which would force me to upgrade the product? Most homeowners don’t replace thermostats, or other home appliances, unless their current ones are broken. I’m in this boat. I’m not planning to buy another Nest unless this one breaks (and if it does so within the next couple years, I would be disappointed and potentially go to another brand).

Does anyone have a Nest thermostat? If so, do you like it?

 

Nest thermostat is my favorite product is a post from: http://requirements.seilevel.com/blog

One of the most useful models we have here at Seilevel, at least in my opinion, is the Feature Tree. It allows you to show a high-level view of all the features in a project (ideally on one page) so that stakeholders, analysts and developers alike can ensure a complete set of features and see the link between the business objectives of the project and the requirements (see the Feature Tree example below). However, one thing that I’ve found through my projects is that you can add dimensions to your Feature Trees, showing stakeholders more information at a glance than just a list of features using color coding.

I’ve personally done this several ways. The first and perhaps most obvious is to color code for releases of a project. Say you’re working a multi-year/release project and want to focus the stakeholders’ attention on the requirements for a specific release. This information would of course live in the requirements tables, but it can also live in the Feature Trees by coloring the Release 1 or whatever release you’re looking at in a different color from the rest (I prefer green, given the usual connotation of green meaning “go”). See the Feature Tree below as an example.

You could, however, color code as many releases as you wanted with distinct colors. I’ve also used two other mechanisms for color coding Feature Trees that both revolved around comparisons; specifically capability gap analysis. For this, if you are comparing one company to another or one product to another, you can use a simple 3 color scheme to denote which features belong distinctly to one company/product, which to the other and which overlap (I use green, blue and red, where red are capability gaps, blue are overlapping features and green belong to the first company/product being investigated). See the Feature Tree below as an example.

 

Finally, if you are comparing multiple companies/products, you can color code with what I liked to call “skittles,” small colored dots on features where each one denotes that a specific company or product utilizes that feature. These work great if you want to prioritize the features that are utilized by the most companies/products or to just get an idea of the features that each company/product has. See the Feature Tree below as an example.

Of course, with all of these mechanisms, you have to clearly explain the color scheme to your stakeholders and include a key on every page. Additionally, you do have to think about people printing in black and white and/or who are color-blind. To work around this, if you are using the skittles, you can make sure that each company/product has its own place on the feature branch so that people can look at the same spot every time to find the dot. If you are color coding the text itself, you could make sure that the features in a certain release are grouped together and put a box around them or something to indicate they belong together or do some sort of bolding, italicizing, etc. to show capability gaps/overlaps.

All in all, I’ve seen great success with using color coding to enhance my Feature Trees. Try it out and let us know about your experiences!

 

Adding More Dimensions to Your Feature Trees is a post from: http://requirements.seilevel.com/blog

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!

 

Trolling for awesome new products is a post from: http://requirements.seilevel.com/blog

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.

Why IT Needs to Know Business Problems is a post from: http://requirements.seilevel.com/blog

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!

Mind the Product 2013 is a post from: http://requirements.seilevel.com/blog

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!

Collaborate on documents during your meetings is a post from: http://requirements.seilevel.com/blog

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.

How To Successfully Manage Software Requirements In A Global Organization is a post from: http://requirements.seilevel.com/blog

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.

“Refactoring” is not a Feature is a post from: http://requirements.seilevel.com/blog

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.

Don’t Hold your Data Hostage! Agile Requirements for Data Maps is a post from: http://requirements.seilevel.com/blog

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.

What Does Project Success Mean to You? is a post from: http://requirements.seilevel.com/blog

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.

Modeling Tip: Make Your Process Flow Easy to Review is a post from: http://requirements.seilevel.com/blog

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.

From Karl Wiegers and Microsoft Press: Co-authoring Software Requirements, 3E is a post from: http://requirements.seilevel.com/blog

Have you ever written a requirement, or, more likely, business rule, that you know to be correct—but, you also know that many people will stumble over it?  This usually happens when the language in the requirement/rule is not familiar to everyone or the concept is complex.  In these situations, examples are usually more helpful than more words, such as:

1. The number must be expressed using digits (example: “7″ not “seven”).
2. A = the ceiling of B/C (examples:  ceiling of 10/3 is 4, 11/3 is 4, 12/3 is 4, and 13/3 is 5).

A colleague and I were discussing this the other day.  He pointed out that sometimes examples are trite and provide more to read/review with no real value.  I agree, don’t use them everywhere.  As a guideline: provide examples if you believe at least some of the people reading the information will sketch out their own examples to understand the requirement or rule.  Or, if you would provide an example if you were discussing the requirement/rule in person, provide it in the document.

There’s another place where examples can come in handy. Once, I was revising some requirements written by someone else.  There was a log of detail, and I understood what was being requested.  But, I didn’t understand the practical application of it.  I like abstraction, which gives flexibility.  Providing examples of how the abstract becomes concrete is useful.  In these cases, be careful no one takes the example as a limit in scope.  Perhaps you have a system that allows users to customize data entry prompts. One example would be that a person can change labels to another language.  However, this doesn’t mean changing language is the only use.  Some users may want to use different verbiage, while others may simply want to change the case of the prompt.

 

Need more help on clearly defining your requirements? Check out Seilevel’s comprehensive list of business analysis tools online.

Business Analyst Guideline for Using Examples in Requirements and Business Rules is a post from: http://requirements.seilevel.com/blog

Lately I’ve been thinking to myself, “What does it mean to be a professional?” It’s a word no doubt you’ve heard thrown around, often in a cavalier way. People take one look at another person and say, “They are not professional,” or view the actions of another and think, “A real professional wouldn’t act that way.” What, then, defines professional?

To be certain, a “professional” is someone who is qualified in a profession. That is the formal extent of the definition, but in everyday use what does that mean? Well, clearly this is tied to a profession. It follows then that every profession has their own standard of what it means to be a professional. For instance, you wouldn’t say a doctor is unprofessional because they didn’t file a brief with the court, and you wouldn’t call a lawyer out on professionalism for not scrubbing into the operating room. As a business analyst, I can’t help but wonder, “What is a professional Business Analyst?”

To help me in my quest for knowledge, I thought I’d poll my coworkers with, “In a few sentences, and in your own words, how would you describe what it is to ‘be professional’?” I had everyone give their role within the company as a context to their comments. Here are a few responses I’ve picked as a point to think things over.

 

Professionals own results and outcomes, rather than “agreeing to work for a certain number of hours at a certain rate”.  Professionals own their mistakes and fix them. – Requirements Architect

 

As business analysts we should be striving to be creating goals and objectives that are finite, measurable, and can be delivered upon. Going further than that, we should be meeting these objectives we set, and should not flounder on our accountability. In fact, accountability is an important part of any profession, regardless of if you’re a doctor, lawyer, or business analyst.

 

Do what it takes to enable our customers to succeed and achieve their stated (and unstated) objectives for a project while treating them and my coworkers with the respect, courtesy and consideration that they deserve. – Senior Product Manager

 

Follow-through and respect. Even if you’re not a consultant and don’t necessarily serve your requirements to customers, there should be a standard of excellence that is universal to all business analysts. Additionally, showing respect to coworkers and customers alike is key. It allows them to put their trust in you as a professional.

 

My perspective definitely isn’t going to be the ‘norm,’ but in my opinion professionalism is being an attentive listener, being empathetic, being honest, and caring about the customer and his/her success in a real and personal way. – Product Manager

 

To me, this comment touches on what I would call “personal” professionalism. While most people would consider the conservative, suit-clad person with a firm handshake to be the epitome of professional, I would rather place my professional trust in a person who is honest with the people they interact with, truly listen, and can create an air of understanding. Business analysts should be producing a front which communicates, “I hear you, I understand you, I will do everything to make sure you are involved.”

 

To be professional means to be competent at what you do, be reliable, respectful, and honest with others, making sure your professional life does not interfere with your work, and always look for ways you can being doing things better. – Requirements Analyst

 

This last comment, I feel, is one of the most important considerations for professionalism. Professionals should be “competent” at their profession. That is, if you are asserting yourself as a professional you should know what you’re talking about, you should know what you’re doing, and you should know where to go from here. Simply asserting that you know what you’re doing is not enough, but often people cannot tell the difference. However, if you are not being honest in your professional representation, and people figure it out, all trust in your professionalism will be lost.

In no way is this an exhaustive list of what exactly a professional business analyst should be, nor does this set out any framework to describe the professional business analyst. I think that as a profession Business Analysis may not be mature enough to garner such standards. However, these are the considerations that must take place. What would you add as a quality of a “professional” business analyst?

I would encourage you, dear reader, to open up the conversation to your fellow professionals and come to an agreement.

 

Want to work on your professional development as a BA? Visit our site for details on Seilevel’s business analyst training.

What is the professional Business Analyst? is a post from: http://requirements.seilevel.com/blog

A Feature Tree is a high-level model that allows the creator to organize features into feature groups, capturing the entire scope of a project into a single model. See how a Feature Tree model can assist you in capturing the scope of your project.

 

 

Want more tutorials? Visit our website for more Seilevel videos

Feature Tree Model is a post from: http://requirements.seilevel.com/blog