When ready to start your Digital Business Transformation Journey, you have selected the platform, and assembled the team to implement (Systems Integrator, Software Vendor, or a collection of contractors) - there even is the Scrum Master. But how do you decide to select the Product Owners? Simple, right? Someone that knows the business, the systems, and has authority.

We are applying the wrong selection criteria.

With these criteria - it is still a 50% chance we get the innovative and transformative digital business platform anticipated, at best. So, what should we focus on instead?

The Product Owner

Before we dive into how to properly select a product owner, let's quickly revisit what a product owner actually brings to the table in an agile delivery. What does the product owner do, and what is the product owner accountable for?

First - there can be more than one product owner - in fact - in most Digital Business Transformation Programs, there are multiple product owners, representing specific portions with clear boundaries within the program. 

To whom product owners accountable? - They are accountable to the business leadership (in particular the program owner - the person with the funding). In very large programs there may be a lead or overall product owner, responsible for the overall product, with the individual product owners responsible for their respective components.

What do product owners do? - They compile the user stories, and verify these user stories on the Triple A scale: in order of least to most important, each user has an Actor (someone does something), an Action (something is done), and an Achievement (the outcome of the action performed). They then map the features proposed by the development team against the user stories, and assign a priority against these features. Finally, product owners test the delivered functionality (feature collection) against the original user story.

How is a product owner's success measured? - A product owner's success is measured by the value created per feature - Considering 80% of the value is in 20% of the features - the product owner guards against "Gold Plating", focusing instead on Minimum Viable Product (MVP) and Minimum Viable Increment (MVI).

Characteristic 1 - The ability to accept MVP

When selecting the product owner, it is important that sprints can be closed with a minimum viable product (MVP) delivered. Acceptance of what an MVP could look like is essential from the very start of the agile delivery, where the users stories are compiled an assessed. The product owner can then assess each feature on its impact on the usability of the product delivered at the end of the sprint. The capacity to distinguish between what is necessary and what is "gold plating" is essential for the product owner.

Characteristic 2 - The ability to prioritise based on value

Front-loading the sprints with a bias for value is essential - 80% of the value is derived from 20% of the features. A successful product owner can assess the value of the features - not just from a particular domain, but within the overall transaction flow of the business, ultimately to how it would affect the customer. 

Characteristic 3 - The ability to see opportunities beyond the challenges

When making a change in the way things are done, by introducing a transformation in the business, it is not difficult to list all the challenges. These can be listed as reasons why things should not be done, or attempted - and the Digital Business Transformation Program fails to deliver on the "Transformative" component. This sounds arbitrary, or even so logical that it is self-evident that a product owner is able to do this. However, experience shows that for most product owners this is a conscious struggle not to give into the "that won't work, let's think of something else" attitude. Some are not able to lift themselves out of it at all! 

All you need to deliver an Agile project is sticky notes, and a place to stick them... So far, this has been true - sort of. The daily stand-up is a great way to provide updates and ask for help - but agile has morphed beyond the small team that is co-located. Products are divided into multiple smaller products, a sprint can focus on multiple streams (or "epics") - and even multiple sprints can be run at the same time. Add to this the complexity of distributed teams, where members are in different offices, cities, or even continents. A board with sticky notes will not suffice, and a daily stand-up simply does not work as an effective communication tool.

Zoho Sprints - the practical way to manage your Agile delivery

Sprints by Zoho is a fully functional Agile delivery application - for small teams, to distributed larger programs of work with multiple sprints. There are other agile delivery systems available, and usually the choice is a trade-off between usability and robust features. Zoho Sprints combines these two elements - the main planning board is analogous to the traditional sticky notes - but the features in Zoho Sprints allow it to be scaled from the very small to the very complex Agile delivery works. Central to each sprint is the board - the digital equivalent of the board with the sticky notes - except, these notes don't fall off, and the board is available to everyone, regardless of location.

Zoho Sprints is part of Zoho One

Zoho One is the "all-you-can-eat-buffet" of business applications. For $50 (Australian) per employee per month, you get access to a full suite of applications to operate your business. Zoho Sprints is part of the Zoho One suite - and as such a great tool to use Agile to implement the vast feature set delivered by Zoho One through the organisation. Try Zoho One for free for 30 days - link below. 

"It is not the strongest of species that survives, nor the most intelligent that survives. It is the one most adaptable to change." - attributed to Charles Darwin (for the quote investigators among us, no, there is no evidence Darwin actually said these words - but it will do for our purposes here).

"A process of change in a certain direction" - Definition 2a of Evolution - Merriam-Webster dictionary.

Sustained change is a long running process, progressing roughly in a single direction, with many side tracks and dead-ends to retract from. Sustained change, therefore, is rarely revolutionary - where many things are fundamentally changed at once - as too many of those will lead to inherent roadblocks in dependent processes, causing the whole system to collapse.

What truly baffles me is that we all know this, yet we still embark on large business transformation programs, hoping that our efforts to direct sustainable change in this revolutionary process will actually work (this time).

We learn in small increments

When in school, we do not start with complex calculus, trigonometry, or elemental particle physics as the objective of the whole course from the start. It starts simple, adding, subtracting, then multiplying, dividing, and so on. Not every pupil will go into the field of particle physics, or quantum mechanics; they will adjust their course along the learning pathway. Why is it that in business transformations, we expect the "Big Bang Miracle" of transformation, when in reality, these are very rare, and even more rarely conducive to a successful outcome?

Revolutions do not bring in the Utopia - evolution does bring progress

Our history is riddled with revolutions, and never has one ushered in the promised utopia. Same for digital transformation - a revolutionary approach (change everything, change it fast) simply has too many moving components, it is impossible to rule out the unintended consequences... worse, it is all but a guarantee that this is exactly where you'll be mopping up the mess after the revolutionary approach.

In conclusion

Small changes allow the team to see rapid incremental progress, while keeping the steps small enough that they will adopt the changes more naturally.

Small changes also allow for mistakes to be made and corrected quickly - it is easier to adjust the direction when small increments are delivered and tested in practice, as opposed to a large transformation with a significant delivery at the end of the project.

Finally, small changes allow for smaller teams working on them - the larger the teams, the less productivity you get out of them (Price's law: the square root of all people in a domain, deliver 50% of the work).

Small and steady increments of good stuff is better than a giant leap into greatness.

"A great start is half the work" - Well that might not be entirely true, setting off on the wrong direction most certainly will be double the work, if not more. So what is a great start when considering implementing new software? Unless you are in the business applications industry, you do this type of work only once in a few years (for some organisations, once in a decade). The following are three simple to use tips, that nobody from the industry has told you. Tips that increase your success and significantly decrease your spend on business applications.

1. What is the most important question

I used to think that "Why" was the most important question to ask. I was wrong. So, what is the most important question? Exactly - what is the most important question! It starts with: "what do we do" - what is the purpose of our business, and what does that mean to our customers. This gives a high level outcome. For example: "our purpose is to provide our clients with....". Then break it down: "what are the capabilities we need to serve that purpose?" - for example (and these are very generic): purchasing, manufacturing, storing, selling, invoicing, managing accounts... Most companies will have these generic capabilities, but the smart ones among us will add some distinctive (if not disruptive) components to it - such as (example) educate our customers, educate the community, connect supply and demand of <...> services as a "man in the middle". For example - AirBnB may have a disruptive business model - but the capabilities for the large part follow the same as everyone else - i.e. acquire customers, sell, invoice, etc. There are a few unique (or disruptive) capabilities in this mix that make the model interesting.

And herein lies a nuance on the "what" question: what can we do different that is a profitable disruption within our market? Whatever answer comes out, there is opportunity to investigate - after all - if you implement a new business application just to maintain status quo, it seems a rather lot of money and effort for not changing. We need to ask the opposite as well- or, deal with our confirmation bias. Especially when it comes to novel and potentially disruptive ideas, we tend to get overly enthusiastic and forget that it might not work out as planned. The two essential questions to ask are: "What are the potentials or possibilities that our strategy may not have the desired results" and "what are the worst case and most likely case consequences if that should occur".

Finally, these capabilities need to be made into something concrete - "What is be done to execute this capability?" - Write this as a form of a story - "As a user, I need to be able to....." and follow up the question with answering "to what end?" - i.e. "in order to.... ".

2. Not all features are created equally

Whenever I would go into an implementation project, and the customer says - "all requirements are must haves, we have culled everything else", my first instinct was "RUN!" - but, that is not an acceptable alternative. The truth is, not everything is required, and not everything is equally valuable. The questions mentioned in the above paragraph leads to a feature set - some of these may indeed be required, others may simply be nice to have. How to go about assessing what is what, and which is which? Ask a follow up question: "what happens if we do not have this feature?" and "what is another way of preventing that consequence?". 

Features fall into the MoSCoW categories (Must have, Should have, Could have, and Won't have this time). I have written about this in other articles, but here is a brief reminder - Must have = business standstill/process halt if not in place, Should have = tangible and measurable benefit, Could have = minor benefit, perceived benefit enabling adoption, and Won't have this time = maybe next time, but not considered now.

Within the MoSCoW categories, each feature represents a value. Ideally, the value is quantified, but at minimum, there is a relative value statement. Stack rank each feature in the Capability/MoSCoW matrix - most valuable on top. Remember: 80% of the value resides in 20% of the features! Like a sound-engineer producing a new album, all instruments, frequencies, and compressions are added or removed based on the value they add or subtract from the overall sound.

3. Bring it together with a system

Having the capabilities and feature values makes sense if they are relatable - A tip to do this is via an Agile implementation collaboration tool, such as Zoho Sprints (you could use a spreadsheet - but that is a lot more difficult to control and maintain) - use the "Epic" as a representation of the capability, and the required feature (as represented as a user story) as a backlog item (of the type story). Features are associated with each epic, and each feature has a MoSCoW classification, as well as a Value Stack Rank assigned. Therefore it is easy to see at a glance how a feature is going to impact the overall ability of the organisation to fulfill a capability.

In summary

• Business applications exist to help fulfill a capability
• Most capabilities are standard across all businesses, with only one or two capabilities making your business unique or disruptive
• Ask "what" - "what needs to be done", "to what end", "what happens if it is not done", and "what can we do to prevent negative consequences if it is not done"
• Assign value to the features that come out of the "what" questions
• Don't be afraid to change some capabilities, or features - you did not implement a new system to keep doing exactly the same things the same way
• Use a collaborative tool to keep track of the capabilities and associated features

If you want assistance, we can help with facilitation of workshops, help you build your capabilities map and assess the feature/value matrix.

Implementing new business software is hard. Way harder than it should be - and usually we are the cause of the complexity. We tend to understand what we do in the business, but we do not fully understand why we do it, leading for overestimating the complexity of the process. There are three simple rules you must follow to contain the complexity.

Before we proceed, this is not written as exclusive to waterfall, iterative, or agile deliveries. Where "requirements" are written in this article, you could replace that for "features" as required.

Work backwards from the outcome you wish to achieve

Every time I hear the phrase "we need everything we have right now, and all the things that make it better - but we cannot go backwards - AT LEAST we need what we have NOW", I prepare for a long project, with many change requests, and not to forget budget and time overruns.

It is obvious that the organisation is not ready to start implementing a new solution - they do not yet know which elements of the old solution are valuable to keep, and which do not add that much value. "Gimme what I have now, but better" is not a specification to which can be delivered. It also does not allow for any trade-off. If your current solution is your starting point, you do not inspire innovation, more likely you try to force a square peg into a round hole.

Instead - ask what needs to be achieved. Instead of writing requirements like: "the system shall ....", write an outcome and how it should be achieved. For example: "we need a higher engagement on our mailing lists" is a good start for an outcome (better would be if it was quantified with a number, say 20%). "In order to measure our progress, we need to be able to measure delivery, open, click, and bounce rates". "In order to obtain these metrics, we need to be able to send email campaigns to recipients with trackers".

By working your way backwards from an outcome, you prevent "requirements" slipping in that have no bearing on any outcome, but are merely a reflection of current operations.

Understand what you can trade - always ask: "at what cost?"

When you have a clear picture of the outcome, you are able to offset the costs of achieving that outcome against the returns. Certain things are simply required, otherwise there is operational standstill, or a regulatory violation. The rest is a simple matter of economic benefit. This can be direct benefit, such as an increase in output, or decrease in costs. This can also be a benefit from which other benefits could derive - such as increased employee engagement. It does not happen often, but when an organisation makes clear that "All requirements are essential, they are MUST HAVES", then there is nothing to trade. The project is 100% guaranteed to fail in this situation. Either the customer does not understand the difference between elements that could cause business standstill, and elements that simply would make things better. By stating that everything is a MUST HAVE, we eliminate the question: "at what cost?". Classify your list according to MoSCoW (Must have, Should have, Could have, and Won't consider now).

• Must have - business standstill, unacceptable competitive disadvantage, or violation of regulations if these requirements are not met
  
• Should have - adding these to the solution results in tangible benefits that outweigh the costs (high value)
  
• Could have - adding these to the solution results in minor but measurable improvement, against acceptable costs
• Won't consider now - adding these requirements results into a "garbage can solution"*, or the cost benefit simply does not stack up.

*Garbage Can solution: All problems are fit into the solution (the garbage can), until it no longer fits. At that stage, a larger garbage can is used, and repeat.

Prioritise for value

Roughly 80% of the value of any solution is delivered by 20% of its features. It shocking when you look at this statistic that still 70% of business applications projects are considered a "failure", either due to budget blowout or failure to meet expectation. When you are aware of this fact, you obviously frontload for value where you can.

In the requirements, as classified according to MoSCoW, add a column for value (make it a consistent period - i.e. value over a year). Now you can stack-rank the requirements in descending order of value; first for the Must haves, then the Should haves, and finally the Could haves.

If you are in an agile deployment, mix the highest value items in the first few sprints (a healthy mix of roughly 65% of the effort on Must have, 25% Should have, and the remaining 10% on Could have). If you are in a Waterfall deployment, ensure the high value items are front loaded, together with the must haves, early on. If you work for multiple releases, it would be good if each release could go into production - which allows for an agile like mix of Must have, Should have, and Could have requirements.

Finally during delivery, the agreement between customer and partner/vendor should be made (written) on what the exit criteria are - and at what stages these could be invoked. It is not necessarily a bad thing to exit a project prior to all the value being delivered. If you have 80% of the value from 20% of the features, and that 80% is already an improvement, then it can already be deemed a success. The remaining budget is almost discretionary spend. To make it worthwhile for all partners, an exit clause could be written that benefits both parties, should both parties have succeeded in delivering high value early on in the project.

To bring it home - Three actions

1. Work backwards from the outcome. Don't give the current (or previous) system be your constraint on bringing that outcome at a reasonable cost.
2. Be very rigorous in assigning the Must have, Should have, and Could have classification. Overestimating the requirement in terms of value is setting you up to not achieve 80% of the value in 20% of the features.
3. Frontload value in your project, and have an agreement that is beneficial to both customer and partner/vendor to exit the project early if a value threshold has been delivered.

Go and ask for a quote for an IT solution delivery, and the first thing you get asked is: "What is the scope?" Seems fair - if you want to get a price commitment, you will be asked for a functionality boundary. But what does this actually do to the delivery of your solution? Nothing good, I'm afraid. You have exchanged uncertainty and risk for limitation and disappointment. How? And more important, how to prevent this? Read on.

How scope creates a prison

In the traditional project delivery, where the solution is a complex set of features with many interdependencies, setting a scope is essential. As a customer, you get some clarity of the functionality you get, and as a vendor you get some understanding of the cost and effort it takes to deliver that functionality. However, simply because there is nothing better, does not make it a good system. Just look at the number of projects that go "over budget". There are many articles written about Scope Creep - the worst kind of creep you can have on any project. But is it?

Consider that the customer does not always know what is being asked. Typically in these projects, the delivery is a much newer solution, newer technology, than what the customer already uses. The further along the project, the clearer the delivery becomes. That is a problem when the scope is set at the beginning of the project.

It creates a prison for both the customer and the vendor. From the vendor's perspective, the scope is the MAXIMUM delivery as agreed with the current budget. Ask the customer, and then the perspective is the MINIMUM features delivered. If you were to draw a Venn diagram, the circles only intersect at one single point - no room to maneuver.

Scope on a Time and Material Project? - we need to talk

There are two main contracting mechanisms in a traditional waterfall project. Time and Material, and Fixed Price. Other machinations, such as Time and Material Cap, and Flexible Scope are nice inventions, but they create more problems than they solve.

Engaging on a Time and Material project? You have to understand what you are buying. As the name implies, you buy time... and material. In other words, your bill constitutes of the time spent by your vendor, and cost made. Regardless of what has been delivered - A statement of work is the initial guidance to the focus of delivery effort, not a contractual agreement to what will be delivered against what cost (typically, you do not see the cost or time budgets in a Statement of Work for a Time and Material project - at least, not if your vendor knows what they are doing).

Much has been said about agile, and much is continued being said. Agile deployments of software fail, and agile deployments of software succeed... And every so often an article pops up which contributes to the common misconceptions that create the weak foundations to build your agile deployment. Let's explore them here.

Misconception 1 - Agile is a project

A project has a defined start, a defined end, and a defined transformation delivered in between of the start and end. Agile has a defined start with the start of the first sprint, but technically, no defined end (you can add sprints or decide to scrap a few), nor does it have a defined end state. The whole purpose of agile is to get features onto the "product" (product is the delivered item or service at the end of each sprint) - with each sprint successful if it delivers an MVP (minimum viable product) or MVI (minimum viable increment or improvement). There is no guarantee what is delivered at the end of the sprint other than the aim to have it as a minimum viable (usable) product. Therefore agile fails the "is this a project" test - and we should not treat it as a project - or you invite yourself to failure.

Misconception 2 - Agile must have a scope

Scope is to put a fence around the requirements of the project - what is included, and what is excluded. If it is not in the scope, it is governed via a change control process, or chalked up as "scope creep" (usually at the time the project is running out of budget). Using agile for your deployment, you focus on features, which are assigned to sprints in such manner that at the end of the sprint it is very likely that a minimum viable product is delivered, even if not all features of that sprint made it to the product. Through the method of points estimating (usually using the Fibonacci sequence), adding a feature of x estimation points needs to be traded with removing a feature or features totaling at least the same number of points. 

Misconception 4 - You must estimate accurately

We'd like to estimate with the highest accuracy as possible, but the undeniable fact is, we (all of us) suck at estimating. We don't know how to estimate. Do I hear some murmering in the back of the room? Do I hear someone say: "our estimates are always accurate?". If your implementation partner says that, and it turns out that what they have estimated is indeed what is billed, you should ask: "what is more likely - my IT vendor has found a way to accurately estimate my custom deployment project even though they do not yet have a full picture of the end product and our internal complexities, or, my IT vendor has padded all estimates to cater for the eventual occurrence of at this moment unforeseen risk?" - my money is on the second explanation. Estimates are like storage space in your house: it doesn't matter how much you have, you'll always fill it. No, we cannot estimate.

What we can do, is relative estimation. We may not be able to tell if A is 10 or 20 hours in effort, we can tell if A is relatively more or less than B. This is where the Fibonacci sequence comes in - we assign estimation points based on complexity - 1, 2, 3, 5, 8, 13, 21, etc. So if A is more complex than B, and B is less Complex than C - we can start assigning numbers. B is the least complex feature in the list - the next question is: how much more complex is A regarding to B? Is A twice as complex? Then B = 1 means A =  2. How complex is C in relation to A? We know that both A and C are more complex than B. If A and C are equally complex, then we assign the value of 2 to C as well. If C is less complex than A - we need to reassign the numbers. A could be 5, B could be 2, and then C could be 3. Note that the Fibonacci estimation method does not translate any of these numbers into time. It is just relative estimation.

An experienced team will have a rough understanding of how many estimation points they can deliver in any given time, but a good method of testing is a "Sprint 0" with a representative loading of estimation points.

Misconception 5 - if I follow all principles of the agile delivery as described above, the delivery cannot fail

Nonsense - In anything worth doing, there is always risk of failure. If your agile delivery is based on the above misconceptions, it is all but guaranteed to fail, unless you actually manage it as a regular project - in which case the chance of success drops to 30% (yes, still approx. 70% of all IT projects fail). Here are some pitfalls outside of the previous addressed points:

1. The product owner does not have sufficient knowledge/experience to define an MVP/MVI
2. Insufficient time and effort is spent on testing against the MVP/MVI requirements
3. The delivery team is insufficiently experienced in the delivery of a certain technology, and this has not been reflected in the estimating
4. The estimation points are assigned by people other than the ones delivering the product
5. The product owner does not accept that not all features will be delivered
6. There is no understanding in the team of value of each feature, and the fact that 80% of the value is within 20% of the features
7. The product owner is "hands off" during the delivery process.
   

Key takeaways

• Agile is not for every company, nor is it for every delivery. But when you do go agile, do not conflate the delivery methods with traditional project management
• Agile does not make you deliver the same features faster. It makes you deliver more value faster by prioritising value first
• Agile does not mean "no documentation". It means limiting the documentation to those documents that are essential in delivery or use/maintenance of the product
• Agile is not magic, but the results can be

Why we are convinced it is not a game

First of all - it just isn't fun. That is just a matter of perspective. Some like strategy games, others love a first person shooter, and then there are those that love the simulation games, and so on. So, I am not going to say: "Of course it is fun!" - as personally I don't find any computer game all that entertaining, I know it comes down to the basic elements of learning, and motivation through progress.

That brings us to the second, and possibly the biggest obstacle with regards to the gaming analogy: it isn't easy to learn, and mastery seems unattainable for us "mere mortals". Only the anointed few (the solution architects and principal consultants) can ever master the implementation of such behemoth of complexity.

There is some truth to that statement - in particular if your software is built on older (read: ancient) architecture, and the design stems from the 80's and 90's from the last century (in business applications, that is analogous to opening a library and deliver your books in clay cylinders filled with cuneiform script). If the last two decades have brought us anything, it is simplification - a simplification that has been enabled by more powerful computers, and more recently, the onset of Cloud. Simply said, the cloud commoditises software - all software. What does that mean? It means that all software is on a trajectory to become easier to implement and easier to use.

Strategy and implementations

What is key to every strategy? Execution. And the key to effective execution? Measurement to adjust. Now this is fundamental to every game, from the very simple shoot 'em up like the good ol' Space Invaders - to the more complex and interactive world of World of Warcraft. How do we know we execute well? We tally the score while playing. How do we know if the strategy is sound? We measure our progress towards the desired outcome - and see if the score is predictable along that path. For example, in chess, you keep score on the number of chess pieces captured and lost - but you track along your strategy if this is according to your plan (i.e. you expected to sacrifice a piece, versus an unforeseen action that resulted in an unexpected loss).

But before we measure our progress, it is very important to realise what the actual objective is. And this objective has to be unequivocally clear with all actors and stakeholders in your project. Typically, these outcomes are all defined differently - the project owner wants the functionality on time, and on budget, the implementation partner focuses on the scope line-items and budget, and for each actor there are different interpretations of "functionality" and "scope". The objective of the implementation is the outcome that needs to be achieved - whatever that measurable outcome may be (more customers, saving costs in the supply chain, increasing inventory turnover by x%, etc).

Shared outcomes make allies out of adversaries

By having a shared objective that is outside of the scope of the delivered functionality, the entire project team has the opportunity to collaborate to that desired outcome. The objective of the implementation is achieving that outcome, or to reach a state that both parties agree is satisfactory (i.e. the additional time and resources required to get to the "perfect" state are outweighs the incremental improvement against the current achieved state). The "Statement of Work" no longer is the guiding document - the delivered features are adjusted based on the measurements of incremental progress.

Key takeaways

I have been in the business of implementing business solution for over 25 years. During this time, I have been amazed at two things: 1). the incredible speed of innovation in this sector, and 2). the incredible inertia of silly requirements that keep us from utilising these innovations. No - this is not an advocacy to just blindly implement whatever shiny new thing that is concocted - I am merely implying that a number of the requirements put up are designed to maintain the status quo - intentionally or unintentionally. Typically, the technical restrictions of the current solution become the most restrictive requirements of the new. Read on for tips how to recognise this.

Where do I put the horse?

Imagine, late 19th century, at the onset of the invention of the Automobile. What if the requirement to be able to harness a horse was maintained? We now know that this would be completely unnecessary, but if the concept of the Automobile is completely new and alien to you, it is a reasonable assumption.

Do you have any "harness" requirements?

Culprit no. 1 - Finance

For the uninitiated, finance is the area where magic happens. Somehow, the finance department makes sense of all the operations of the business, and quantifies that neatly in a profit and loss statement and balance sheet. For sure, you don't mess with that! However, not all requirements are affecting the production of the statements and reports required to run a business - some are just... there to keep things running as they were for years.

Example - booking time in 10 units per hour

Those that are booking time, in the "old days" did so in 6 minute units. This is driven by the invoice not dealing in time, but units (base 10 instead of base 60). With the introduction of actual time sheets, that are able to capture actual time (either as duration, or as a from - to record), it is now possible to capture actual times, and these are converted to base 10 units in the invoice (yes - in most systems, you can set 6 minute intervals in the conversion). And what was a requirement at an organisation I did some work for a while back? You guessed it: we do not accept writing time sheets in actual time, please modify this to reflect our 6 minute units...

Example - operational reporting from the general ledger

Before the 1990's (yes, integrated systems have been around that long), the financial system was used for reporting, and the operational systems (as far as they were not paper-based in the organisation) were used to drive the process. Both financial and operational reporting had to come form that one system that had all the data consolidated into one reportable database. Before a decade ago (or so), creating reports was quite complex and expensive. Since the turn of the millennium the complexity and costs have gone down considerably, and now it is almost "end-user" work to create meaningful reports out of multiple data sources. Yet, in quite a few organisations, there is a very complex ledger structure, split out with a ledger account almost on product and customer level (I have seen an organisation with a general ledger containing 21000 ledger accounts, split by customer(!)). The cost and complexity to map all ledger accounts to operational activities is significant - it is also highly error-prone requiring regular reconciliation verification activities. In modern (anything from the last 20 years, really) systems, collating financial and operational data into a meaningful report is considered a given - yet the requirement for such detail in ledger setup remains at some companies.

Example - after-the-fact purchase approvals

Every company needs to control the purchases and bills. Especially when the systems are not integrated between finance and operations (see above - operations used to be mostly manual), a purchase invoice needed to be verified prior to payment. With the onset of integrated systems and approval workflows (mid-2000's), any invoice that comes into the business is either an expected non-purchase invoice (i.e. utilities), or the purchase order is somewhere in the system. These orders are pre-approved as a purchase, and in case of a physical good, matched to the receipt of the product (so-called three way matching - where the invoice, the receipt, and the original purchase order are matched for consistency). It makes little sense for these purchase invoices to go through a separate workflow yet again prior to payment, increasing activity (cost), complexity, and a delay in paying suppliers (supplier relations). Instead of separating the unexpected non-purchase order related invoices from the pre-approved invoices, many times I see companies adding the double workflow on the purchase invoice for approval for these expected invoices. The outcome? 100% approved, or if there is a rejection, it is due to a discrepancy found in the three way matching.

A new system is not "magic"

New software systems enable a more streamlined and efficient process. That implies that it facilitates doing things differently. What no new system can do is make a convoluted, outdated, and inefficient process work smoothly. It actually costs you more money in implementation, and modification of the system, to make it adapt to poor processes. It is a fallacy to expect a new system to bring in the process utopia, when you do not change your process.

How to establish the true nature of requirements

In most cases, the list of requirements for a new system is composed by people that know the current system (because they use it). It is therefore not a surprise that the requirements read like a summation of activities performed with the current system, plus a wishlist of things that would make it better. Often you hear the phrase "at the very least we want all features we have now, plus some more". Given the old system has been in place for 5 to 7 years (or sometimes even over a decade), and the rapid innovation in the business application space, it is no surprise that requirements tend to hold you back in the status quo.

Here are some steps to establish the true nature of your business requirements:

• instead of compiling the list what people do, establish what outcome they need to achieve
• for each outcome, ask what benefit this outcome brings (or what "disaster" is averted) - try to quantify this
• establish if the new solution can achieve the outcome - identify if it does so in the same, or a different manner
• assign a classification to each requirement (MoSCoW - or Must have, Should have, Could have, Won't have (now)) - is a great tool to manage expectations
• use stepping stones, not a big leap forward analogy - make every release slightly better than the last, instead of aiming for perfection and never delivering anything to production