Tag: Methodologies

The One-Eyed Man in the Land of the Blind

Written by Colin Hammond on July 19, 2018. Posted in Articles.

Almost everybody these days sizes software story points. But what is a story point? To every agile team, it means something different.

For a self-governing agile team, the story point is principally about effort and time spent than a measurement of delivered functionality. Tasks that don’t deliver functionality are also measured in SPs.

The job of a software Project Manager is far more than just representing a burn-down chart; he needs something more user-oriented, and more universal. Appropriate metrics are essential for a well-managed project. SPs are inadequate for PMs except for the estimation and measurement within the context of a single agile team.

As it happens, there is a good technique for software project estimation and measurement. Not many people are aware of it, nor how to use it effectively. BAs have a great opportunity to introduce this and raise the certainty of software projects.

Before diving in on the answer, let us take another look at the wider context.

Budgets for software changes are typically assigned at the project level, not for a stream of work (which is how Agile teams are set up). Agile teams’ estimates are based on story points, which can vary wildly from team to team and organization to organization.
Senior IT management expect PMs to give reliable delivery dates, firm cost estimates based on expected functionality – all up front. Story points are not a suitable metric for development contracts.
Agile practices are very effective at producing software – the customer usually gets what they want, in due course. However, Agile teams struggle with whole project estimation.
Agile teams self-manage using (arbitrary) story points and a finite capacity to deliver work each sprint. However, senior IT management cannot budget, measure or report based on story points as a business metric.

Part way through my career I learned about a technique from the 1970’s called Function Point Analysis (FPA). I was shown how, when used thoughtfully, this technique can bring incredible predictability to software projects. FPA is the process of counting Function Points (FP), a measure of software size from the user’s perspective. FP’s are the only ISO standard approved measurement of software and are even suitable for development contracts.

So why have so few people heard of FP’s? There are likely to be several reasons, but mostly, they are considered old-fashioned, and they are hard to count. Counting function points has always been a manual process. Around 20 years after the initial methodology was invented, an updated revision was published that addresses many of the criticisms of the original method. Cosmic Functional Sizing (cosmic-sizing.org) is the latest incarnation of this ISO standard. Cosmic, brings the technique up to date for modern software architectures and is a principle based method.

Function points can be counted even before the software is written. They are far more appropriate than story points or lines of code because they focus on the measurement of functionality from a user’s perspective.

There is substantial data available on the statistics of past projects measured using function points, specifically the writings of Capers Jones and data available from ISBSG.

Function Points are about size measurement, but they can also be used for estimating and managing other aspects of your software project:

Size: FPs to be developed or changed as part of the project.
Scope change: as above.
Quality: defect potentials per FP and defects found per FP are two examples.
Schedule estimates: number of months needed to delivery a given number of FPs,
Schedule adherence: adherence to an expected delivery rate of FPs per month.
Resources allocation: Staffing and costs needed to deliver an amount of FPs
Earned value delivered: FPs are a direct indication of useful user functionality.
Vendor estimate validation: compare proposals against typical industry costs per FP

For the last ten years have used function points on every software project. They have given me great insight, very quickly. Most of these projects have involved Agile software delivery teams and I have measured the FP’s alongside the story points. This works just fine. Story points are the primary metric for output and productivity within a scrum team and FP count is my primary metric at a vendor, project and even portfolio level.

Once I discovered how effective and valuable FP’s are to me as a PM, I was surprised that I had not come across them before. It seems that so few people are aware of, or appreciate the value of them. There are perhaps a few reasons for this:

FPs are considered old-fashioned and irrelevant to modern techniques. This objection is no longer valid having been addressed by the latest generation of Functional Sizing Methods, Cosmic-sizing.org
Functional Sizing is considered to be hard to learn. Yes, I spent many months learning to become competent and certified in counting IFPUG FPs. The Cosmic method is considerably easier to learn. And now with the automated counting tools doing the heavy lifting, there is less need to spend time learning the methodology.
Cost, you have to pay to obtain the IFPUG manuals. The Cosmic method is a free open-source project.
Counting function points takes time and businesses have neither the time nor inclination to allocate to the sizing activity. A false economy of course. Nevertheless, there are tools now on the market that count FPs for you, from pre-existing code, see CastSoftware, or from user stories / requirements, see ScopeMaster.
There is little understanding of the potential co-existence of FP’s alongside story points. This is what I have practiced for the last ten years it works just fine.
Development vendors generally avoid quoting in FP’s. I believe that this may be because it would equip the purchaser with a metric to negotiate a lower price.

I highly recommend that you take some time to look into the free project cosmic-sizing.org. Once you have the ability to count and use function points, you will feel like the one-eyed man in the land of the blind and eventually colleagues will turn to you for guidance.

Case Study – Gap Analysis – Off the shelf product implementation

Written by Chitra Manoj on July 12, 2018. Posted in Articles. 1 Comment on Case Study – Gap Analysis – Off the shelf product implementation

Project Background

The project that has been referenced in the case study was a complex multimillion dollar solution in the financial services industry that was successfully implemented.

The goal of the project was to replace the legacy system that was used for the core banking services as well as the online banking services with an off the shelf product that was built on better technology.

Objective

The objective of this case study is to emphasize on the key task ‘gap analysis’ and the value add it provides to off the shelf product implementations.

Problem

Like most of the IT projects, lack of documentation on the legacy online banking solution made the analysis harder, requirements had to be identified by reverse engineering.
Since the ‘to-be’ product was an off the shelf solution, there were limitations on customising the functionality.
The stakeholders were from various business units within the organization with different work priorities.
It was assumed that the chosen product matches all the required functionality of the existing solution and gap analysis was not recognized as a required task before project planning to agree on timelines.

Solution Approach

Meticulously compare the new product offering with the existing solution and identify the gaps. i.e. functionality that will no longer be available in the new solution/functionality that will be different in the new system.
Identified and logged all the gaps in a ‘gaps register’. There were approximately 800 plus gaps identified.
Each gap was analyzed for the following
1. Does this have an impact on the customer either in terms of user experience or reduced functionality or any other? If yes, how many customers will be impacted and what will be the communication strategy.
2. Is there a security/compliance issue? If yes, then what is the mitigation plan.
3. If an existing functionality is not available in the to-be solution, assess the business need for the technical solution and raise a change request to get the changes done or identify if there a process workaround.
4. Prioritise each gap based on the remedial steps identified and track the progress.
5. Does the solution to address the gap require staff training?
Recurring workshops were scheduled to
Regularly track the gaps identified
To keep the key business stakeholders informed about the gaps
Agree on the action plan for each gap.
To prioritize the actions for implementation.

Pro’s

Project Owner & key stakeholders were extremely happy with the gap analysis process as the gaps register provided them with full visibility and had an audit log of all the decisions made and why they were made.
Avoided a lot of potential post-implementation complaints and issues.

Con’s

Time-consuming activity which was not planned or expected in the project.
Required lot of extra effort and persuasion with stakeholders and project management office to do the right thing.
Incurred additional costs for the changes to be implemented.
Additional effort was included in the project schedule, though not attributing to huge delays.

Lessons Learnt

To avoid surprises, for off the shelf product implementations, once the product is shortlisted, perform detailed gap analysis early in the project to scope requirements and effort estimation.

Success Factor

The gap analysis activity contributed majorly not only to the success of the project but also helped me (business solutions analyst on the project) get a lot of recognition within the organization.
The gaps register, and the process involved in the analysis proved to be a value-add as it was referenced as a template to analyze and prioritize new features for future projects and enhancements.

Well-defined Data Part 1 – Series Introduction

Written by Dan Tasker on July 3, 2018. Posted in Articles.

The objective of this series is to take an in-depth look at data required for an IT-based business information system.

Techniques and concepts for business analysts thinking about and documenting entities, attributes, and relationships will be presented. This introduction to the series defines what is meant by well-defined data and the rationale for it.

What Is Well-defined Data?

Data, to be well-defined, should be both well organized and well specified. Well-organized data follows the old proverb, “A place for everything and everything in its place.” In business analysis terms this translates to “An entity for everything and every attribute in its appropriate entity.”
Well-defined data begins with determining the best business name for an entity or attribute. From that point the defining continues, capturing a definition plus details needed to get that data up and running in an IT-based system. Ideally some form of data dictionary would be used to record these details. Throughout this series one example of a data dictionary template will be used. It will be seen to include entity properties such as current volumes and growth rate, and attribute properties such as data formats and precision.

Who Needs Well-defined Data?

Outdated IT System Replacement — Any organization that wants to build or acquire a new system to replace an outdated one needs the best possible data definition for data in the current system. There will be fields that turned out not to be of any business use. There will be fields originally intended to be used for one thing that ended up being used for something else. And there will be data needed by the business that the current system does not support. Some or all of this unsupported data may be managed by the business outside the current system in spreadsheets and such. The best possible definition of all this data is needed to support designing or acquiring a replacement system, migrating data to it, and training current users where to find the data they need in the new one.

IT System Vendor — Any vendor of commercial off the shelf (COTS) software needs the data underlying its software well defined. This information is used to convince prospective customers of the software’s capabilities, and to respond accurately to requests for quotes (RFQs). When a sale of the software is made, well-defined data is needed to support system configuration, data migration, training, and development of any bespoke reports or interfaces required.

Requirements Documenter — A business analyst responsible for producing requirements documents should include well-defined data in those documents. A high-level requirements document (Stakeholder requirements in IIBA BABOK® terminology) typically will have a glossary rather than a fully-detailed data dictionary. The glossary name and definition will be useful as input to the data dictionary developed later in the project. A detail requirements document (Solution and Transition requirements in IIBA BABOK® terminology) ideally would include a full data dictionary as a central point of definition for entities and attributes referenced in detail specifications for screens, reports, interfaces, and batch processes.

Other Waterfall SDLC Team Members — Any member of a team involved in waterfall development based on signed-off requirements needs well-defined data. This includes:

Designers
Developers
Testers involved in integration, end-to-end, and user acceptance testing
Data migration team members
Trainers — of end-users or train-the-trainers
Technical writers of user manuals

People in all of these roles look to requirements documents to support their deliverables. A central place where data is defined, either in each document or centrally for the project, would be of great benefit. NOTE: If available, an organization-wide data dictionary should be referenced for existing business data definitions, adding to that resource any additional project-defined terms and their definitions.

Agile Scrum Team Members — As user stories are written and refined they will reference entities and attributes that need to be delivered. Maintaining these in a shared data dictionary would mean consistent delivery of the data component across different epics or features.

What’s Ahead in this Series

Entities — The next three articles focus on Entities. The first will discuss generic business entities. These have business names and definitions common within the IT systems that support functions common to all organizations, such as accounting or human resources. For example, the entities General Ledger Account and Journal Entry within accounting, and Staff Member and Position within human resources.

The following two articles focus on line of business-specific entities. The line(s) of business an organization is in influence the entity names applicable to its products, customers, sale-related business events, and locations. For example, an airline sells a Ticket to a Passenger on a specific Flight. A public library acquires a Book Copy allowing a registered Patron to Borrow it from a Branch.

The first of these two articles discusses five generic line-of-business functions — Marketing, Product Development, Sales, Customer Care, and Product Decommissioning. These are seen to represent a product lifecycle common to all organizations. The following article focuses on each of the four primary business entity concepts a given line of business deals with — products, customers, sales, and locations.

Attributes — an attribute’s properties vary based on its intended purpose within its entity. Articles will be dedicated to discussing each the following purposes:

Being the entity’s Primary Business Identifier — E.g. Customer Number, Employee Number, Account Number.
Naming — E.g. codes, abbreviations, people, products, buildings.
Quantifying — E.g. Currency amounts, product dimensions.
Point-In-Time Happening — E.g. Date of Birth, Purchase Date/Time.
Describing — E.g. in sentences, photographically, graphically.
Classifying — selecting from a pre-defined list. E.g. Customer Type, Skill, Gender.
Identifying an external entity instance — E.g. customer’s driver’s licence or credit card details.

Attribute History — Two kinds of attribute history will be discussed — business-meaningful history and audit history. Business-meaningful history means that users need visibility of changes to an attribute’s value over time, as part of normal business processes. E.g. Account Status, Discount Rate. Audit history is only needed in exception cases, where an attribute’s value is not correct, and the business wants to know the source of the incorrect value and what the previous value was.

Relationships — The three classic relationship types — one to many, many to many, and one to one — will be discussed. The use of screen mock-ups as a mechanism for defining these will be compared to how they are normally defined using entity/relationship diagrams.

Derivable Data — Different levels of complexity of data derivation will be discussed, including simple totalling, point-in-time summations (such as year to date figures), and complex rule-based derivations (such as discount amounts based on historical purchases).

Additional Topics — As this series evolves there may be additional topics that prove worthy of presenting. One that I know is lurking in the background is mandatory data (attributes or relationships). Stay tuned.

Click here for Part 2 — Generic Business Entities

The Death of the Traditionalist

Written by Jon Derbyshire on June 28, 2018. Posted in Articles.

In the same way innovation is leading to disruption in the tech industry, so too will individuals in traditional roles continue to innovate, experiment and try new things.

This is a good thing! It really is. Innovation and experimentation often leads to big wins or changes that further industries, professions and companies.

However, along with innovation comes failure. ‘Fail fast, fail often’ seems to be the new mantra of the start-up industry, and it’s also bled significantly into agile environments. It’s become an acceptable practice in companies all over the world, but we must remember…….failure is still failure even when we learn from it.

There is a fine line between risk and recklessness. Measured risk can have big payoffs. Measured, being the keyword.

How Does This Affect Me?

Business analysis, at least in terms of how it is viewed nowadays, is still a relatively young discipline. As such we have a great scope and willingness to embrace new methods and ways of working. Over the past 5 years, there has been a huge increase in the number of business analysts calling themselves agile business analysts. I too am guilty of this despite having more years working in waterfall than agile.

Death of the Traditional

I love what I do, and because of that, I spent a lot of time absorbing new materials related to the practice and wider industry. From traditional means such as books and blogs to newer modern ways including webinars and podcasts. All of these channels offer great value and insight for learning and are largely driven by the contributor’s experience of successful practices.

What I find much rarer these days is hearing stories of the times when the analysis was wrong or failed to offer value. These examples tend to only come up either from individual 1 on 1 conversations, or as part of examples from materials aimed at newer business analysts just starting out, on what to avoid doing.

Reading between the lines, it appears to me that some of the more traditional methods, once applied as best practices, are slowly dying out. As such you rarely see them mentioned in articles, posts or examples from the last 5 years or so.

I’m talking of the techniques I once studied 17 years ago at university or applied often in the early stages of my career when the business landscape was very different and the internet was still in its earlier and often frustrating stages, such as SWOT, PESTLE, MOST and CATWOE.

These seem to have been entirely replaced with modern techniques evolved for more modern and agile times such as user stories, use cases, wireframes, story mapping and MoSCoW.

Don’t Count Them Out Just Yet

Maybe one of the reasons for the decline of these models may simply come from the natural evolution of the business analyst cycle. Many of the industry veterans who got their start and were ingrained in these methods have gone onto bigger or different things. Those who came up or into business analysis in entirely agile environments probably haven’t ever been shown the more traditional/older models. Innovation has won out and is enabling BA’s in modern day do a very good job using only the newer sets of tools.

Innovation of Old

Fashion trends, language and pop music all seem to experience cycles. What was once in style, went and of style and then had a revival. Maybe the same could happen in the business analysis industry.

OK, that probably is a step too far. But what if, the innovators and those looking to continuously adopt new methods to try, innovated by reviving the traditionally taught models

Example 1 – MOST

For those unfamiliar with MOST analysis, it is a model used for evaluating whether the internal project you are working on is aligned to 4 main corporate strategies

Mission – Where does the business want to go/purpose of the business.

Objective – Goals of the business.

Strategy – High-level approach to achieving the goals.

Tactics – Means to implement the strategy.

I don’t really see MOST used much these days but without any deep background, it’s quite easy to see its relevance to modern and agile environments.

Imagine that you are working for a game development company. Your company has a vision or a goal driving it towards where it wants to be. You’re working with product owners, product managers, basically all the main stakeholders to come up with games to pitch to the company owners. You’ve brainstormed lots of ideas and now it’s time to build the business case for each. Applying MOST analysis to your game ideas can a modern day take on the traditional MOST analyst.

Let’s actually apply MOST to a real-life example (made up on the spot to demonstrate the ease of use). Let’s take Rockstar Games – the originators of Grand Theft Auto and red dead redemption. Imagine it is the early stages of the company and we are going to look at whether the game ideas being pitched will fit into the company ethos build using MOST. Those which do will be taken forward. Those that don’t will be scrapped before wasting the founder time.

Mission – To develop games the founders would want to play that doesn’t conform to the rules or standards current games developers are working within.

Objectives – Develop whatever they want, whenever they want and not have to answer to anyone.

Strategy – Create in-game controversy / real world feel / give the players moral choices but with complete freedom to destroy traditional morals.

Tactics – Gorilla marketing strategies /controversy in the news / word of mouth

For anyone who has played, seen, or heard about grand theft auto you will know that the game would have been a resounding YES. Whereas, if you were to be reviewing a pitch for a game like ‘The Sims’, you would have likely rejected the game pitch before the presentation stage and gone back to the drawing board.

Example 2 – PESTLE

PESTLE analysis is used to evaluate the environmental factors which impact a company. It’s a great tool to apply when thinking of starting a company going or moving into an established market. Something which probably happens more than ever in modern times. Providing a deeper understanding of certain areas which will need a more robust and comprehensive analysis done before going to market, PESTLE helps to focus on the important facets within 6 main attributes:

Political (current and potential influences from political pressures)

Economic (the local, national and world economy impact)

Sociological (the ways in which a society can affect an organization)

Technological (the effect of new and emerging technology)

Legal (the effect of national and world legislation)

Environmental (the local, national and world environmental issues)

And again let’s apply it to a modern company. This time I will pick a young company proving extremely popular in the fitness industry at the moment – Gymshark

Political	Must be aware of taxation rules around new and growing companies Pressure is being applied to the government to increase health and fitness initiatives Increased political volatility across the world
Economic	The weakened pound may increase costs of purchasing from other countries Potential difficulties on securing finance in a difficult economy Inflation Pressures Retail struggling and consumer spending being squeezed Traditional marketing being replaced by social media marketing
Sociological	Must be fashionable and appeal to modern day influences (i.e. youtubers and Instagram fitness accounts) Sizing must not alienate large parts of the demographic. Need to remain independent and not flood the market devaluing its niche appeal
Technological	Modern fabrics cost more Must use flattering cuts The delicate balance between fashion and function
Legal	Must compete with mainstream competitors without infringing on any copyrights Health and safety rules
Environmental	Environmentally friendly packaging Environmentally friendly policies are a must

PESTLE isn’t ground-breaking, but it does highlight areas of analysis that will need significantly more analysis. Its application to agile is just as relevant as it is to waterfall. It can be applied at strategic or product level. If nothing else it highlights potential issues and risk for the risk register and for teams such as development, design or logistics to consider.

Innovation through Foundation

As with all innovation and evolution, what sticks will be that which tends to work. In today’s continuous improvement focused environments such as software or infrastructure, we all need to be trying new things and applying new knowledge.

But let’s not leave behind all of the foundational techniques business analysis was built on. Let’s consider innovating through brilliance at the basics as well as new innovation. Applying modern takes to traditional models can really add value and prove fruitful. After all, despite it being a much different time, these foundations built the industry that all brought us to this point. They shouldn’t be discounted or left out of today’s application.

A Roadmap to Agile

Written by Judith Mary Khan on March 21, 2018. Posted in Articles.

Transitioning to Agile is well worth the effort and benefits, but the way is not always easy and can be filled with issues and frustrations, as well as wrong turns.

To try and be successful in your transition, use a roadmap for the effort, and plan to spend some time and effort on the journey itself. Steps to start can look like this:

Pick the right person to lead the transition effort. This person will have energy and enthusiasm, and insight into Agile.

Pick a small project, one without a lot of complexities surrounding its next release target, and one with team members ready to learn.

Use a collaboration tool that may already exists in your org or purchase a limited number of licenses on something new, or select a different method to collaborate such as a wall board.

Get together with team members and set some goals, gain a common understanding of what comes next, and what comes later.

Expect the change to take some time and energy.

The lead of the transition effort can secure the collaboration tool and users’ access or create the wall board, schedule the meetings, and answer questions as they surface.

Plan for the first phase:

Pick a practice or a handful of practices to start with, such as changing requirements to stories, then start using the tool or wall.

At a round table, get everyone’s buy-in and ownership-of a workflow, keeping it simple for this first phase.

Schedule and set expectations of a daily standup.

Estimate your stories or translate estimates from the Project Plan.

Start sprinting, with a Sprint Planning session.

Have a retrospective at the end of every sprint for a while, even if just to share, question, and vent.

By roles, have each team member do some part in transition prep, a possible list could look like the one below:

Agile Lead: secure the tool or wall for collaborating, schedule standups and a Sprint Planning session for 2 or 3 weeks forward. Use Agile terminology, to start making it common language.

Product Owner (BA): start to translate the highest priority requirements into stories and organize them into epics, facilitate with team member inputs.

Create the backlog and prepare stories for Sprint Planning. Readiness means that the stories will have the details of the requirement, be useable by developers and QA, and be estimated. Work with the business to start ordering the backlog by priority.

Developer: Contribute to grooming the former requirements, now stories, with the PO/BA and give your best-guess estimates.

QA: Contribute to grooming the former requirements, now stories, with the PO/BA and start deriving your Test Plan and Test Cases. Follow the Backlog order of priorities.

Lead (again) be ready for Sprint Planning, and in the beginning, invite everyone to contribute and participate.

Leadership needs to be involved too, especially at the start and through the first phase. Whoever has the power and authority to set a directive needs to step forward and communicate clearly that this is desired by the organization and that the participants need to participate. This is critical in overcoming resistance, even among team members who seem to be eager and willing initially.

The next step is to set the objectives for phases 2 and 3, and onward. This will accomplish two important aspects of success:

setting shorter term goals that are easier to reach
measuring success by outcomes

As well, creating and displaying a phased roadmap can instill the idea that Agile is ongoing in its adoption, continuous as the team grows into it, and a practice that can optimize over time.

And, information can be shared and leadership can take note that there will be slow changes not only in delivery, but how people are working. At its best, the list below is how teams and individuals transform:

Authoritative hierarchy -> self-organized
Silo’d work -> interactive
Predictable and rigid delivery of work -> nimble, and changing or changeable
Documentation heavy -> documentation light
Formal communication -> transparent and informal communication

These changes are significant for teams who experience them. Many people have spent a career honing and executing specific skills and may need time to change their way of working. Others, may have recently finished school where Agile-like practices were the norm. Changes in the workspace atmosphere and social interactions should not be underestimated. These personal, and interpersonal changes require support and attention from leadership. Stress and resistance can best be eased through inclusion, especially in decisions, and fostering ownership of results by the team members themselves.

After at least 3 sprints, a team will be ready to look back and start planning for Phase 2. And in an Agile approach, they can set sights on what Phase 3 will look like. Post and socialize your roadmap to see what comes next, and be sure to come together often as a team at round tables!