About Analyze

Analyze Consulting was founded in 2007 with the purpose to help businesses get to the bottom of and solve business inefficiencies. The cornerstone of this dream is a passion for quality business analysis and project management.

We are motivated and rewarded by helping businesses be more efficient and solve problems.

We believe that the best way for us to do this is to start with a deep and thorough understanding of the problem or opportunity. The discipline and insight that we apply to this enables us to be confident and truly objective about defining the best possible solution.

Our vision is to be the partner of choice in solving business challenges through the appropriate use of technology, process and people.

Get In Touch

Email: info@analyze.co.za

Tel: +27 (0)21 447 5696

Cape Town Office:
The Studios – Unit 314
Old Castle Brewery Building
6 Beach Road
Woodstock
7925

Johannesburg Office:
Block A
Homestead Park
37 Homestead Road
Rivonia
2191

Business requirements analysis

/Business requirements analysis

Is it really only a choice between waterfall and agile?

In today’s project world, you’re either waterfall or agile.  Never both.  Never something in between.  But why has it become such a big waterfall vs agile debate?  And do we fully understand the two extremes these two methodologies present? Over the past few years, waterfall as a project methodology has definitely taken a back seat in favour of the new, cool kid on the block – agile.  Throwing around terms like scrum, lean & extreme programming has certainly become very on trend.  Unfortunately, most companies don’t quite “get it”.  They like the thought of getting things done faster and being more flexible, but they don’t actually want to align with all the principles that go along with being fully agile. What companies should be asking themselves is:  What is waterfall not giving us? And what can we do to improve on those things?  Therefore, we’re no longer seeing waterfall as the enemy and agile as the magic wand, but instead taking a closer look at what it is we actually want to achieve and then making changes to help get there. We’ve found that most companies actually just want to be more adaptable, and in order to achieve this goal, an iterative approach has proven more likely to lead to success.  You want to be in a position where you can test a new product, service or concept as quickly as possible to confirm whether it’s going to work or not.  Prototyping, as an example, is a great way to test something quite quickly, then make changes & test it again.  In this way you’re also ensuring that you’re getting real customer input from very early on. We’re not saying that going agile is wrong in any way.  We’re just saying take a step back & try to understand why you feel you need to go agile.  The following questions should help to identify your main areas of concern: What makes your projects difficult to manage? Why do project end results miss the mark in terms of customer value? Are there processes that run up costs unnecessarily? How good is your quality assurance?  Have you considered using test automation to assist? What is the general feeling towards the project methodology currently in place? A full agile adoption requires a company-wide culture change.  By understanding your core issues, you can take smaller steps towards where you want to be without having to jump from one extreme to the next.  A project methodology on its own is not the be all and end all.  It’s purely a structure that can help shape your actions, but it’s not your only option for getting things done.  The key is to find the right fit for your specific company needs, be it a blend, a purist view, or something quite custom to you. Want to talk to us about how your company can become more adaptable? Get in touch.  Share this:

Creating context for The Context Diagram

Often, when business analysts start projects, they are required to define the scope of work that will be involved in implementing a new system. One way to do this, is to draw up a context diagram that graphically illustrates the full scope of the system. What is a context diagram? This is a simple but powerful tool that clearly shows the system under consideration and the various external entities that interact with it.  A context diagram shows at a very high level: The system boundaries The external enties – these could be people or other systems The information that flows between the system and these external entities External entities may include various stakeholders and systems that have direct interactions with the system under consideration. It is not to be confused with the use case diagram which is more detailed and includes detail down to the process level. Why is it important? This very useful tool is often overlooked by business analysts as they believe it does not add much value. The team at Analyze, however, believe that it is a critical step in the initiation phase of a project. The context diagram is a tool that will be a central reference point for scope. How to draw one up? The key is to ensure that the context diagram depicts the project scope simply but accurately. Here are our top tips on drawing the context diagram: Start by drawing the main system under consideration in the middle of the page. List all external entities around the system. NB. Only list those external entities that have direct contact with the system. Taking each external entity, describe the relationship it has with the system. This relationship includes – what kind of information the entity will require from the system and what their main interactions with the system will be. Represent this relationship with a line between the entity and the system. Use an arrow on each line to indicate the direction of the information flow, either towards the external entity or towards the system. Describe the information that moves between the entity and the system. Information may only flow in one direction. Follow step 3 and 4 again for the opposite relationship i.e. relationship between the system and the external entity. An example? Take for example a new e-commerce website being developed for a retail chain. The main system under consideration will be the e-commerce website. The various external entities may include customers, staff, management and payment system. Customers can register on the system, view different goods for sale, place orders, make payments, track orders etc. Staff can update inventory (prices and goods) on the system, view customer orders, track customer orders, process orders placed by customers etc. Management can access reports on goods sold, user statistics, stock levels etc. The payment system can process payments, send notification of successful/failed payments etc. Ecommerce Website Example You can see from the example above, that the context diagram is really valuable in defining the scope of a project at a high level. This ensures that all project stakeholders are on the same page from the get go. Having problems defining scope? Contact us today to find out how we can help you in defining the scope of your project. Share this:

Questions to ask when selecting a software vendor

With continuous improvement being the key to maintaining a competitive advantage, many companies are turning to software solutions to help streamline their business processes. But as much as software can help to reduce costs and improve productivity, selecting the wrong software vendor can have quite the opposite effect. Here are 7 questions we suggest you ask during your vendor selection process: 1. What are your credentials? It’s important to do a bit of background research on each vendor you’re considering. You want to be sure that the vendor is well-established with solid plans for future growth and development. New start-ups introduce a lot more risk, so be sure that’s something you’re willing to accept before proceeding. Also ensure that the vendor has all the necessary credentials and certifications relevant to the type of solution you are looking at implementing. If they are not able to provide these, back away immediately. 2. What do others have to say? Reference checks are an absolute must, just be sure that you’re getting a true reflection. Customer references from companies within the same industry are key. Also be sure to ask how long they’ve been a customer as new customers may not have hit any real issues just yet. Casting a wider net to online reviews, published articles and industry expert opinions can also be very telling. 3. What after-sales support do I get? Sales teams are notorious for telling you exactly what you want to hear in order to seal the deal. This is why a carefully considered project & post implementation Service Level Agreement (SLA) becomes crucial. You want to ensure that any issues or defects are dealt with timeously and with minimal impact to your business, and that the vendor’s maintenance & support teams are available exactly when & where you need them. 4. To what extent is the solution scalable/customisable? Predicting the future is a challenging task. This is exactly why the software you choose needs to have the ability to grow and adapt along with your business. You do not want to find yourself in a position where you have to change your software solution a couple of years down the line because it can no longer support your business needs. 5. Are there any hidden surprises? Be sure that you have the full picture when it comes to fees payable. Vendors do have a tendency to be less forthcoming about extra fees relating to items such as software modules that may carry an additional cost, onsite training or support costs, ongoing maintenance fees, etc. The rule of thumb is: When in doubt, ask more questions. 6. What is the Total Cost of Ownership (TCO)? You have to consider all of the direct & indirect costs related to the software you’re purchasing. This includes not only the actual software cost but also the associated hardware & data centre costs, the implementation cost, end-user licencing, patch / enhancement / upgrade costs, as well as ongoing support & maintenance costs. 7. What if things don’t work out? Two things you have to be clear about up front are: 1) Who owns what? and 2) What are the costs & criteria related to cancelling the agreement? By getting these items out of the way early you can avoid lengthy & costly arguments later on. Is your business embarking on a Request For Proposal (RFP) process? We can assist with vendor selection and critical assessment. Contact Cathy at Analyze on 021 447 5696 or email her on cathy@analyze.co.za to find out more.   Share this:

How a minimum viable product can help you test new product ideas

Silicon Valley entrepreneur, author and pioneer of the Lean Startup movement, Eric Ries, defines a Minimum Viable Product (MVP) as “the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. In product development, a MVP is seen as a product with just enough features to gather learning which can then support the product’s ongoing development. It has become a popular approach for its ability to reduce product build cost & associated risk. This is because it allows you to test assumptions early on and in an iterative way. Imagine for example you spent the last 2 years building what you thought was going to be the next big thing. During these 2 years various assumptions would have been made about your customers and how they will be using your product. Now, come launch day, nobody’s buying. But why? It almost always comes down to incorrect assumptions which end up becoming a true product killer. With an MVP you’re able to get something to market much quicker which in turn allows you to start testing and learning before further money is invested. It is important, however, to understand that a MVP is not just a product with fewer features. It’s whatever you can present to customers to convey your idea while also testing a predetermined set of feature or usage assumptions. The basic process comes down to 3 steps: build, measure and learn. These 3 steps are then repeated again and again, each time with a clearer understanding of what changes or additions will bring you closer to that final product which will truly fulfil your customer needs. When organisations are presented with the MVP approach for the first time, two questions usually crop up: 1. Isn’t a MVP the same as a prototype? While both are used to test viability of a product, they’re used at different stages of a product lifecycle and also aimed at different audiences. A prototype is a model which is typically presented to a small group of people to prove viability of a planned product. It’s usually a throw away piece of work not intended for deployment to customers. A MVP on the other hand is the first version of a product that’s fit for release. 2. Can’t you also test a product idea using focus groups and market research? While these methods still have their place for collecting customer data, they don’t quite match up to a MVP’s ability to get real insights from customers actually using your product. Of course, a MVP approach is not the only approach to product development, and your company may prefer to go a more traditional route. All we’re saying is that we’ve seen how it has assisted businesses in achieving a higher product hit rate with less money spent. The key is to ask yourself: What are the core functions that we need to build in order to prove this solution? If you go into product design with this hat on, you’ll save a lot of time and money by not focusing on non-essential items that can be added and tested at a later stage. Are you embarking on a new product journey, but not quite sure where to start? We can help guide you through the MVP process.  Contact Cathy on (0)21 447 5696 or cathy@analyze.co.za Share this: