12/03/2011

Proof is in the Reports

You can create an application that meets the customers expectation and still have a failed project.

Because, as most of us in IT know, reporting is the last thought of every project.

So by the time the Reporting Department is handed a list of reports to create, that's when the potential design flaws appear.

Let's say you have to tie the application data to another data source / database.

Yet the app developers did not think through their design when creating the database to allow it to interact with other data.

So there's no 'direct link' between systems.

And that is what we call a 'design failure'.

Who created it?  The project manager, the business analyst, the developers, the users, the entire team.

Why, because they did not include the reporting department in their analysis.

Well guess what, the application is already in production

A little late to be redesigning tables, do you think?

Well, in our case, we have to meet State mandated reporting requirements.

So what does that mean, that means the software vendor needs to modify their application, ASAP.

So in a sense, the reporting department is little bit like QA.

If the biz rules don't jive with reporting, the app ain't gonna fly.

Because now the software needs modification.

Which takes time and money.

I really think Reporting should be included in a lot of application design meetings so these things don't happen downstream when time is limited.

It's always easier to do things right the first time.

And there you have it.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.