Requirements Wokshops: Documenting SIPOC via UML

    BA Video Tip: using XMI to capture business context for requirements... Producing a model (a visual representation of the business process) is an effective tool to provide context to the concerns or needs business owners express during requirements workshops. As a follow-up to a blog entry published last year,  where we went over the advantages of using SIPOC charts in conjunction with UML activity diagrams to structure requirements elicitation and verification sessions, the video clip below demonstrates how business analysts can save time and effort in documenting the results of requirements workshops, if they employ XMI-compliant tools such as EA Sparx Systems, ArgoUML, or Modelio. The video shows how we have customized our production of Activity Diagrams in Modelio to automate the transfer of SIPOC charts into a web-based requirements management tool. We use a custom LAMP database to manage requirements, nevertheless, if your business analysts use excel or word, or any off-the-shelf requirements management system, the principle is the same, as long as the modelling tool is XMI compliant, the investment on time required is in customizing the import of the XMI file into your requirements repository. Enjoy the clip (It is silent and < 2...

03 April 2014 / Hits:581 / Go to Article...

Bringing business analysis best practices to ITIL® Service Management (part 2)

    Babok® task: Conducting Stakeholder Analysis         Continuing with our suggestions on how to integrate business analysis best practices into ITIL contexts, let us focus on the conduction of stakeholder analysis. Once again, we have to stress that BABOK is not prescriptive on when and how this task (or any of the other 31 BA tasks listed in BABOK) should be carried out by the business analyst during a project. BABOK only makes a point on the possibility of executing the task, whenever the inputs required to execute it are available. In our practice, requirements managers normally conduct stakeholder analysis during Service Strategy. Their first effort, at a higher level, takes place to support the preparation of the business case. Then, after the new or changed service is approved, they conduct a more comprehensive analysis of all stakeholders, focusing also on IT and implementation subject matter experts.(*) What is Stakeholder Analysis? As soon as the business need is defined, the business analysis team needs to pause for a moment and identify who may be affected by a proposed change in services or who may have a stake on the business need being addressed. Similarly, once...

17 September 2013 / Hits:2802 / Go to Article...

Bringing business analysis best practices to ITIL® Service Management (part 1)

    Babok® task: Planning the Business Analysis Approach       We are all familiar (business folks and technologists) with the typical business analysis work carried out during IT projects (the requirements workshops, interviews, documentation, etc.) however, beyond these visible activities, there are a few less known tasks, like planning the business analysis approach for a project, which are also important to ensure that business analysis is well-executed and fully integrated into the project management process. As depicted in the diagram below, in ITIL contexts, planning the business analysis approach could take place during Service Strategy(1), as an organization approves a business case and is initiating the design stage for a new or changed service: What is planning the business analysis approach? The business analysis team needs to pause for a moment and consult with stakeholders to determine the best approach to perform all business analysis work required to charter the service: How and when in the project lifecycle will business analysis tasks be performed, what techniques will be used, and what deliverables will be produced. Even though adapting business analysis activities to waterfall, AGILE, or any hybrid software delivery methodology would first come to mind to many...

10 September 2013 / Hits:2780 / Go to Article...

If the mountain won’t come to the prophet… (Part 2)

  On how technologists either endure the wait or the blame in IT projects and why ITIL v3 could use an extra bit on business requirements.       Here is your PMO’s and technologists’ dream, in short: A business case has been approved already for an IT initiative. A group of business process owners and subject matter experts walk into a requirements workshop, and as solution designers sharpen their pencils to begin elicitation, the business crowd starts passing around activity diagrams that describe in detail how tasks will be carried out in the context of the new system. Not only that, business folks also have brought these neat “use case bundles”, organized by process, and describing business requirements and business rules for the new system, risks and opportunities the business expects requirements will address, etc. There is even a measure of monetary value anticipated from each requirement. Some eyes glisten as a business manager sets aside on the table “just in case” a separate list of requirements that will be out-of-scope for IT: The line of business has actually identified many feasible changes to existing processes that could address some requirements without resorting to IT implementations. That is...

21 August 2013 / Hits:1422 / Go to Article...

If the mountain won’t come to the prophet… (Part 1)

    On how technologists either endure the wait or the blame in IT projects, and what CIOs can do about it.       The burden of proving project ROI is on business sponsors; however, the challenge is on the CIO and on technologists in general to perform a careful balancing act of partnering to deliver solutions that meet the sponsor’s expected ROI, while facing extreme pressure to always implement ASAP. It is only fair that for IT to share this responsibility on expected value from projects, the business should ensure a clear handover of its expectations (Yes we are talking about monetary return on product delivered) via stating and restating ROI at critical decision forks during the project. As straightforward as it sounds, I believe that in many organizations there is an accountability gap complicating this handover during one specific phase in the IT project lifecycle. Let’s have a high level view of an IT project workflow, represented in the diagram below as five consecutive tollgates in which the expected value of a project is stated or restated, and handed over to players in the next stretch. The representation spans from enterprise analysis (pre-project) all the way to...

09 August 2013 / Hits:1524 / Go to Article...

Combining Customer Centered Design and Voice of the Customer

  If you are reading this at a Starbucks, waiting for your CTO to arrive with his MAC, as the two of you are going to have a joint design session to build the next successful app. This article is not for you. (You believe you know 99% of what your potential customers want and your technologist is ready to listen to you through 10 AGILE latte iterations, until all knowledge is synched and design is crisp and ready for production) But for the majority of us involved in IT projects where stakeholders are arrayed in a succession of tollgates, from corporate sponsors and project management officers all the way down to testers and implementation support specialists; it is harder to deliver value to customers if this collective challenge is not met via a mix of IT delivery approaches (AGILE, UX, etc.) and business process improvement techniques (Lean/ 6 Sigma, BPM, etc.) Combining Customer Centered Design (CCD) and the 6 Sigma’s Voice of the Customer at different stages of the project lifecycle is a good example of adjusting techniques to match the different thinking patterns of business and IT stakeholders. In an IT initiative that has customers as end users...

23 July 2013 / Hits:1296 / Go to Article...

Tip: Make sure your team understands what you mean by "requirements"

  We throw around the word requirements during different stages of an IT project, assuming that the team is on the same page on what requirements are. But let’s pause for a moment and think: Have we ever walked IT and business stakeholders  through a quick definition of what this word means in the organization? When stakeholders talk about requirements they are usually focusing on the “set” of requirements that is most relevant to them, and unwittingly, their conflicting priorities can lead to waste in misunderstandings, or even errors in tactical decision making. For example, if you hear statements from your team such as we need an “agile business analyst” because there is not enough time to go through every single requirement, and we need to prioritize. Is the person talking referring to design requirements (specs) needed to build the solution? Or, are they talking about not having enough time to gather a requirements baseline that can be used to determine the gaps in the solution? An Agile approach would definitely help the team on the former case, while the latter situation simply means the project is heading for trouble: if there is no gap analysis, there is no product...

02 April 2013 / Hits:2358 / Go to Article...

Adopting AGILE does not mean shortcuts in enterprise analysis work

  Of the four value statements presented in the AGILE Manifesto, the fourth one (We value responding to change over following a plan) causes frequent misinterpretation among technologists. New AGILE practitioners need to keep in mind that adaptive methodologies were meant to address the lack of flexibility and fluidity during the construction of a solution design. In that sense, the arrival of AGILE 15 years ago exposed the value of delivering software in an adaptive way, emphasizing customer collaboration over agreement on a comprehensive statement of work, or a big plan to deliver it. This has been certainly the greatest contribution of the AGILE movement: The realization that software that works could be delivered collaboratively by the team with just the right amount of specification up front. Nevertheless, AGILE enthusiasts are sometimes so excited about avoiding big design and big planning that they tend to carry their skepticism on “big” efforts beyond the solution domain, all the way back into the problem domain. Thus, some AGILE teams would fall into the trap of also avoiding what they would perceive as “big analysis”, and would dismiss even the need for any preliminary structured requirements documentation. This slant against starting a project...

09 March 2013 / Hits:8571 / Go to Article...

Tip: Using SIPOC to verify requirements for IT

  A SIPOC chart is an artifact borrowed from the Six Sigma methodology. It stands for Suppliers, Inputs, Process, Outputs, and Customers. We find this chart useful when we are verifying business requirements and rules from stakeholders. A business requirement expresses what needs to be done by an actor to mitigate a risk in a process, or to take advantage of a business opportunity. A business rule expresses what conditions should be met with the same intent. If used in conjunction with a UML activity diagram (see pics below), a SIPOC allows us to structure a verification session with business stakeholders, and to maintain a consistent language in the documentation of the requirement. The business analyst and the stakeholder will review each task in the activity diagram asking the following questions: Who supplies the output of the task? (a supplier) Who receives the output? (a customer) What does the supplier need to carry out the task? (an input) What is received by customer? (an output) It is often the case that, during the original “capture” of the requirement, stakeholders overlook documents or conditions, or call suppliers and customers in processes differently, depending on the business unit culture, hierarchy, or location....

14 February 2013 / Hits:2750 / Go to Article...

Using BPM to gather requirements for Enterprise Software Implementations

    From my own experience in enterprise software implementations, many organizations fail to understand how delivery and adoption of a good IT design greatly depends on having been engaged in sound Business Process Modeling (BPM) at the beginning of the project. Technologists tend to regard BPM and Change Management as strictly “Business Side” specialties whose work products are one step too far removed from the Software Delivery Life Cycle (1). PMOs think of mapping processes as an activity that precedes requirements management for the IT project, and in many cases, IT business analysts are called in to gather requirements using business process models that have been “finalized” by a BPM analyst. I beg to differ. I think a project team implementing enterprise software can save a lot of effort if analysts carry BPM and requirements gathering concurrently, structuring requirements elicitation around the delivery of a thorough to-be business process model (2). I believe that business analysts can ensure good quality and completeness of business requirements only when they decompose processes down to the lowest level, exposing all underlying risks and opportunities. If I may describe three simple stages we follow in our practice, I think they illustrate how BPM...

28 January 2013 / Hits:10776 / Go to Article...

 

 

 Corporate Legal Counsel

 

 

Value of Management Consulting Subscriptions for local Startups Expertise:

 

  • Mergers & Acquisitions
  • Corporate Governance
  • Complex HR Contracts and Labor law
  • Business Bankruptcy Procedures
  • Trade Import/Export issues
  • Inmigration to Spain

 

 

Value of Management Consulting Subscriptions for local Startups Ignacio del Olmo

 

Ignacio provides complex strategic legal and compliance services to Spanish companies with a primary focus on commercial agreements, labor law and business bankruptcy procedures.

 

Through his own practice ADDI Abogados, established on 1996, Ignacio is legal counsel to mid-size construction companies, specialty contractors, and meat-packing companies; all businesses with an average workforce of 200 employees and over 35 million dollars revenue.

 

Ignacio has a Juris Doctor from the Basque Country University at San Sebastian, he is member of the Bar Association of Biscay, and has obtained the CAP certification, which further qualifies him as a legal professional in all member states of the European Union.

 

 

Value of Management Consulting Subscriptions for local Startups Asier Barrenetxea

  

Asier has 14 years of experience and an extensive background in corporate law and trade issues. Another founding partner of ADDI Abogados since 1996, he is counsel to companies engaged in international trade, including the first Spanish export consortium, comprised of 11 manufacturers trading in 20 countries.

 

Asier has a Juris Doctor from the Basque Country University at San Sebastian, he is member of the Bar Association of Biscay.

 

 

Value of Management Consulting Subscriptions for local Startups Ainara Basualdo

 

Ainara is a junior partner at ADDI Abogados, specializing in Spanish immigration law.

 

She obtained her Juris Doctor at the Universidad de Deusto,  (Bilbao, Spain) and she is member of the Bar Association of Biscay since 2005.

 

> Back to Spain Business Services