There's been plenty of discussion in both literature and general media about how most software projects fail. There are plenty of reasons for failed projects: from inadequate requirements gathering to poor project management to plain incompetence. Some of the problem starts at the C-Suite where projects are actually identified and initiated -- for asking to automate (presumably with software) something that maybe has no business being automated.
My simple advice to most CEOs and CIOs about project management starts with a question: can you methodically and manually repeat the thing you are trying to automate? If the answer to that question is "no" then no PMO, no project management technique, not even the smartest most talented people in the world can help automate something that can't at least be repeated consistenly manually.
This advice of asking a simple question about repeatability might sound so obvious as to not even bother asking it but it becomes perilous not to do so. At the heart of most failed software automation attempts is a failure to understand the workflow and gather the right requirements. That's pretty easy to figure out. What's not so easy to figure out is: why is the workflow so hard to gather requirements for? It's probably because the workflow, while it seems consistent at the high level, isn't repeatable enough consistently to describe in software. Perhaps parts of it are, but maybe the entire workflow isn't.
So, as a senior executive that may not be leading the project, but may be green lighting it, what you need to do before making a decision is have your project managers describe that they can clearly repeat (manually and consistently) what they are trying to automate. If not, get the process engineering guys in there to work on the process before the geeks get in there to work on the technology. The rule is simple: if you can't repeat it manually, don't bother automating it.
As you point out, workflow is huge to this process-- and that's why we created Arrow. SharePoint users need powerful reporting, document generation or B.I. systems that SharePoint alone doesn't offer. With Arrow for SharePoint, you have those capabilities.
It's a natural fit. You don't have to wait on IT, because you can design and edit reports in Word, Excel and PowerPoint. You save a big chunk of time in report design, and you can run, schedule and share files easily. (No more bugging the tech group for what you need.)
Our customers are using Arrow in a number of different ways. Some use Arrow for designing, generating and distributing reports such as invoices, inventory tallies, financial statements, insurance policies, customer account summaries, product usage reports, certificates and more. Others use it for doc gen and mail merge – an automated way of producing letters, forms and contacts.
Then there are companies that use Arrow for business intelligence. Companies harvest in-depth data and generate BI reports for internal and external use with reporting, analytics and data mining. And organizations use the Arrow's dashboard features to present their data in an up-to-date visual summary that's easy to grasp.
That's the what. Here's the how.
One of the biggest expenses in the report creation process correlates to the design tool's ease-of-use. There's little learning curve because you design templates in Microsoft Word, Excel or PowerPoint. Our customers have found that creating and revising reports is at least 10 times faster than with other reporting systems.
And you don't need to learn complicated code in order to insert data into your reports and other documents, because wizards and drag-and-drop functionality connect templates to their data sources (SQL databases, XML files, and Excel spreadsheets). You run or schedule reports with the click of a button from within SharePoint, and you can generate documents in a wide array of outputs. To sum it up:
Arrow Report Design
Arrow Data Layout
Arrow Report Generation
You don't have to take my word for it. Check out our SharePoint reporting system for yourself.