Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
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.
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:
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.
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.
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:
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.
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:
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.
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.
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
When you hear the terms â€śriskyâ€ť and â€śinvites failure,â€ť do you imagine a successful project methodology?
The debate between waterfall and agile methodologies can be found in any analystsâ€™ meeting of the minds. The linear approach of waterfall methodology runs the project in one large cycle. Agile methodology takes the project in cycles, taking time at the end of each cycle to re-evaluate priorities and keep risk low. Â Dr. Winston W. Royce coined the methodology term â€śwaterfall,â€ť however it may have just been by accident. In the 1970 paper Managing the Development of Large Software Systems, a graphical depiction of the software lifecycle is presented. We see the flow of requirements from a top-down structure, all pooling into the testing phase.
When the testing phase of a project following the waterfall methodology is in place, it is essentially the end-all of the project cycle. If a change is necessary, the team doubles back to the requirements phase. â€śEither the requirements must be modified, or a substantial change in the design is required.â€ť (Royce 2)Â Relating the aforementioned term â€śriskyâ€ť to a project in this way, a team or business might think twice about adopting this methodology.
In the field of economics and investing, risk is often mitigated by diversification. You never want to pool all of your resources into one industry, country or mutual fund. Letâ€™s suppose you place your entire investment into the Brazilian copper industry. What happens when a small disruption occurs to your single portfolio? Risk can be a multiplier of loss- thus, any disruption (hyperinflation in Brazil or a natural disaster) will become exponentially more disastrous to your wealth. It seems obvious here that you would not want to risk all of your investment in this way. Software development methodologies are similarly applicable to the risk factor. Taking the waterfall approach is like placing all of your funds into one risky investment. A disruption, mistake or incorrect analysis may not be discovered until testing. At this point, it is too late to pull out your investment. Your schedule and/or costs will take a hit.
Dr. Royce makes this point throughout his paper. The â€śoriginâ€ť of the waterfall method begins by illustrating the flaws within it. The latter pages of the paper outline ways to mitigate the risk of the waterfall method. Diversify your project by allowing a bilateral flow between stages. Be careful not to place all of your investment into one portfolio. Your team may be able to avoid any mistakes or changes, but why take the risk?