Should you export data to Excel and Word?

Question

I'm the Project Manager for a large application that customers use to collect data on whether their businesses meet certain medical and financial standards. They generally answer a survey explaining how their surgery meets/doesn't meet the standards.

The application has a tool to analyse this information, so that owners of a group of surgeries can see overall how the surgeries equipment are doing .

The owners of the groups are asking for the data to be exportable to Excel or word. I've posed this to our development team, and they don't believe that exporting huge excel or word sheets of data is worthwhile. There arguments are based on:

• The data could be huge to export
• There is no way for them to do anything useful with that many pages
• How would this work for users who use the iphone/android app of the tool

I'm in between a rock an a hard place with them and I'm not sure how best to convince them that this is what we need to do (short of putting my foot down and demanding it!).

Answer 1

Exporting to Excel is a solution, not a requirement. You need to go back to the owners and get them to detail their functional requirements for the data. Once done, then hand it over to the developers and let them propose a solution. It may end up being Excel because, as you wrote, it's already there, or it might be another solution that meets the requirements.

You have to bang each solution up against their benefits, costs, risks, and other penalties. The fact that Excel is already there and they know how to use it is certainly a benefit, but the owners might not know of or are under estimating the impacts of some of the penalties they will have using Excel and end up in the long term unhappy. In contrast, building a new solution will cost money and take time and they will have to learn it--costs and penalties--but it may cure of the impacts of Excel and, in the long run make them happy.

None of this you know yet; this has to be analyzed and a case built for each solution. But everything starts with getting proper requirements from the owners.

Answer 2

As a principle, whether having an Excel is "worth" (business-wise) or not isn't up to the development team to decide. They have to be able to tell whether it's feasible, and objectively tell what are the pros and cons (i.e. it won't work when you have more than 1.000.000 rows of data), they can also advise the client on whether this really solves their problem or not (and if not, constructively be able to propose another valid solution), but they can't refuse to implement a feature just because they think it's worthless.

That said maybe the problem has not been analysed enough, and the dev team and the client are clearly not on the same page yet; so personally I'd put them together so that they can better understand the problem and collaborate to find the best solution. The client might not have fully expressed his real need, and the development team can maybe come up with a different idea...

Answer 3

I would change my mindset from "How can I convince them?" to "Do the user really want to Export to Excel?" and "What solution would be make my client happier while making money?"

1. Talk with the stakeholders. They might think of Excel as a familiar way to describe the functionality. (A solution, not the requirement). But they might prefer Excel anyway (A direct requirement). In this case:
2. Look for alternatives. For example, CSV files can be opened by Excel and are easier to compare. They are usables on Linux and Mac and it should be easier to develop.
3. Make clear to the customer that you will make whatever solution he wants. At this point you are not worried about working more hours. You are worried about developing a solution that might not work for them. Afterwards you might talk about costs if it is an issue.
4. Make sure that the client understands the problems. For example, you could create two dummy Excel files and tell them. "How would you compare them?"
5. Check if the data is too big for Excel and some conservative performance metrics (It might take one hour to export to Excel in a nightly batch proceess)
6. Ask "What do you plan to do with this Excels?". A backup? You should be able to backup the database. A report? Could you generate the report automatically?
7. Once the customer takes a decision send the minute to have a written proof that they accepted the consecuences. Make sure to keep the email easy to find.
8. Explain to the development team that this is a direct requirement from the customer. Not from yourself and your efforts to look for a better solution. Thanks them for their input. Even if the customer was inflexible you will be better off having explained the potencial issues beforehand.

Answer 4

I work in a very small office and have to for-fill a lot of the Scrum roles myself, so I have to balance the sides and arguments in my head for such decisions, this one was a simple decision for me, even though the Backend guy was unable to do the task (I do my own now).

I created xml spreadsheets for Excel based on what is actually displayed in an Actionscript DataTable (one huge string put in a notepad saved as .xml), besides a CSV copy of Flash Datatables.

The creation of Excel spreadsheets at the back end is trivial I can not conceive of a scenario that makes arguing over doing it are worth the time rather than just doing the request. Even turning the 1 datatable into a 3 sheet excel with parameters dates and disclaimers was not particularly difficult.

I work very closely with clients but I am never 100% sure what all of their end requirements are, giving them excel outputs means they can do the 80% of all the possible uses and interpretations of the data for 20% of the effort.

The important thing was not to get the excel in the software but to get the real problem out of the team.

Answer 5

Thinking as a technical person If the information is being stored in a database of some description its typically not too difficult to grant read only access to the tables that the users want to see and then have them import the data directly from excel bypassing the application front-end (developers don't have to do anything) either using excels data import functions or using customised VBA scripts.

Thinking as a manager Talk to your Business Analyst to add the requirement in a meaningful form or alternatively ask the Product Owner / Project Sponsor / boss like person to prioritise the work. It does sound like you are in a 'solution mind frame', which is not the job of a PM. Just because people love excel doesn't mean that they actually need an export to excel feature, sometimes this can lead to security risks.

Answer 6

You could simply put your foot down, and give the customer what they want, but so long as the developers don't get why the feature is useful, they're unlikely to implement it in a useful way. They'll give you a pointless Excel export, which won't be used, and they'll get to say "see, I told you so".

I think the best thing to do is to bridge the gap between the users and the developers. Take a few developers, preferably the ones closest to the front-end, and the ones that are most 'people friendly', and have them shadow the users for a day. Let the users show them what they want to achieve and why it's useful to them. At worst, you'll make sure that the feature actually does what the users want (rather than what they say they want) and at best, the users and developers will reach a more creative solution that really solves the problem.

After all, it's not the user's job to design the software, and it's not the developer's job to choose the requirements. They have to work together to create something of value.

Then, if you really want to get it right, get the users and the developers to wireframe some mockups together. Test these mockups on other users to make sure they understand and then discuss them with the team before implementing them.

Ultimately, this is the sort of stuff that your interaction designer/ux manager should do. It's understandable if you don't have one of those, but I recommend working towards having one. Take this as an exercise. Send three developers to interact with the users. Pick the one that the users responded to the best, and who seemd to like the exercise the most, and start giving him/her more design-like responsibilities. Not design as in photoshopping what the buttons should look like, but design as in collecting user stories, mocking up and usertesting potential features, and working with the other developers to figure out the implementation details.

Answer 7

Exporting large data sets to Excel can be very powerful and make your application that much more valuable to many more users. Excel has such a rich feature set that to try to duplicate it would be a waste of your developers' industry knowledge.

Users can filter, sort, chart, and pivot in Excel in nearly any way they choose. Are you able to define every possible workflow the users need and add that to your app? What about the user that wants to do some data spelunking and try some non-obvious pivots?

As for huge data sets the question is how huge? Exporting to a database for Business Analytics may be a better choice if the data set is large enough to choke Excel. More data gives me a larger sample size and confidence, so I don't see this as a negative.

As for mobile users, I don't know that I'm doing any heavy analysis on my iPhone. If I can get reports on my phone bring it on. Don't let this stop you!

Finally, I agree 100% with Grimm the Opiner, "the scrum team doesn't get to decide what is or isn't a user requirement". This is clearly up to the product owner.