Integrating project schedules with other applications

[BernardErtl]

If you were buying new project management software for your company, and the system you selected came in two versions - one storing all data in a proprietary format and one storing all data in an open format (that can be easily read/altered by humans and/or other software), which would you choose?

Ie. which concerns would drive your decision, ease of integration/add-on possibilities (open format) or project data security (closed format)?

Bernard Ertl
eTaskMaker project planning software

 

[PDQBach]

Project management? or Project scheduling?

Ah, heck, it doesn't matter.

Functionality -- pure and simple. Everything else you mentioned is a waste of evaluation time.

 

[johnherman]

Unless you have specific security concerns and prefer to add the additional layer of proprietary data formats to your security plan, I would opt for the open standards database. It gives the added advantage of being able to query the data in ways that perhaps the original software did not foresee or allow.

-------------------------
The trouble with doing something right the first time is that noboby appreciates how difficult it was.
- Steven Wright

 

[BernardErtl]

Thank you John. I was hoping that this forum might have a wider audience of IT folks who have experienced the needs for integrating project scheduling/management software with ERP systems, inventory systems, etc. (or merely manipulating/interpreting it differently than the base functionality allows) as well as security concerns over access and security (Sarbanes-Oxley anyone?).

PDQBach, I understand your cynicism, but this is a real consideration for many corporations when IT has a say in the acquisition of a new software system. My question was posited as both versions having the same functionality. The question is not superfluous.

Bernard Ertl
eTaskMaker project planning software

 

[PDQBach]

And that's exactly the problem: IT has a say in software acquisition when it is of no concern of theirs (and I come from an IT background -- programmer, analyst, consultant, manager ...)

The user department is buying a hammer -- nothing more, nothing less. IT aren't buying anything.

If the issue is a corporate one (i.e., an enterprise-wide PM system) why are IT's concerns appropriate? If the requirement is to link to software product ABC then the evaluation criteria is really quite simple: can it or can't it? It does not matter what the data format is. The two concerns of IT are: can it be installed on the existing and projected future platforms and can the data be backedup/restored using the current backup/restore mechanism.

You said that both products offer the same functionality. I, frankly, don't think you've done a full analysis on the products since no two competing software products offer the same functionality. What you _may_ have meant is that the evaluation-specified functionality showed no difference between the two products. This is an entirely different matter.

If true, then your decision-point questions should not be data formats but TCO issues and here you'll find items like training, availability of a pool of knowledgable users, etc., come way ahead of open/closed file formats and data storage.

"Hammers".

Think "Hammers" not "The Construction, Repair and Maintenance of Hammers".

 

[BNPMike]

the needs for integrating project scheduling/management software with ERP systems, inventory systems, etc. (or merely manipulating/interpreting it differently than the base functionality allows) as well as security concerns over access and security (Sarbanes-Oxley anyone?).

Sorry to add to the neh-sayers but I've currently got about 300 systems I'm looking at and your description is more dodgy then any of them. How does Sarbanes Oxley come into linking Microsoft Project to SAP?

I certainly dump information from databases into Microsoft Project but that's because there is an easy interface (eg via Excel) not because of the format the data is actually held in.

 

[alexhu]

How does Sarbanes Oxley come into linking Microsoft Project to SAP?

SAP - financial system

access to financial systems (for whatever reason) covered by Sarbanes Oxley regulations

Alex

 

[BernardErtl]

Is Poor Project Management a Crime? (EVMS and the Sarbanes-Oxley Act)

IMO, access to tampering with project schedules will become more important as CEOs & CFOs are criminally liable for the results. Ie. Sarbanes-Oxley will affect security concerns over data access.

PDQBach, I am not currently evaluating any specific software. The original question is a hypothetical. I am developing a new scheduling engine and looking for feedback from IT types. While I wholeheartedly agree with you that IT should not choose what tool the workers can use, the reality is that most corporate purchases these days will not happen without their blessing.

BNPMike, what description is "dodgy"?

Bernard Ertl
eTaskMaker project planning software

 

[BNPMike]

Sarbanes Oxley is about ensuring that financial reporting systems are not polluted by incorrect figures. I can't see how a project planning system affects this. You can tamper with schedules to your hearts content. That won't directly affect the correctness of any figures on any systems. Access to systems is not directly connected to project plans. You can plan to blow the World up. It's only when you start to try and do it that an issue arises.

 

[johnherman]

Unless perhaps, there is an attempt to tie MS Project costs to costs in the SAP General Ledger or elsewhere. Is this the point you're trying to make, Bernard?

-------------------------
The trouble with doing something right the first time is that noboby appreciates how difficult it was.
- Steven Wright

 

[BernardErtl]

Any company with large, long term projects may be basing a significant portion of their financial forecasts upon the cost projections of their schedules. CEOs & CFOs are criminally liable for misrepresenting financial information. Should the schedules misrepresent cost forecasts, they are responsible.

The SOX goes much deeper than just the accuracy of financial projections; it touches on many areas that affect project management within an organization. To be compliant with Section 404 of the SOX - Management Assessment of Internal Controls - CEOs must establish and maintain “an adequate internal control structure and procedures for financial reporting.” Section 409 - Real Time Disclosure – mandates that companies must disclose on a rapid and current basis “material changes in the financial condition or operations of the [company], in plain English, which may include trend and qualitative information.”

As a result, companies undertaking large projects will need a process that provides detailed cost/schedule metrics for all projects with time-phased cost reporting and continually updated completion estimates. Senior management will need visibility into this project performance data at all times along with the confidence that the underlying process is sound.

Knowing how the real world works with corporate office politics, security and data access to prevent tampering should be a real concern.

I'm gathering from the responses in this thread so far, that the issue does not appear to have been considered yet by most?

Bernard Ertl
eTaskMaker project planning software

 

[BNPMike]

Sarbanes Oxley is such a canker that a) my mate's Head of IT has been on stress leave for months (well known international brand company) and b) many companies are considering de-listing.

It is total pants.

 

[PDQBach]

Two comments:

First: SOx is, from a project point of view, _highly_ critical if the project is (or is a feeder to) a financial system. In those cases, the project deliverables (Note: *not* the project itself) need to be rigourously reviewed to make certain that they comply with the Act's requirements. To allow for that review, the PM must make certain that appropriate (time-consuming, zero-value-add) tasks exist in the project schedule for the reviews and approvals to occur.

(For Non-US PMs: If you think the extra-territorial reach of the bill may have an impact on your project activities you should discuss the situation with corporate legal to see what tasks and mitigation strategies might be appropriate.)

Second (to Bernard Ertl): hypothetical situation or not, the answer is still the same. You're developing a hammer. People who evaluate your hammer _might_ have an evaluation criteria concerning the "openness" of the file/data formats but they will be making their decision based on the functionality. It's an IT mindset to focus on stuff like files and documentation; it's an end-user mindset to focus on "what's it going to do for me." Once you decide who you are going to sell to then you'll know what to emphasize. If your product delivers something to a profit centre then you'll focus on some areas; if your product delivers something to a cost centre then you'll focus on different things.

 

[BernardErtl]

People who evaluate your hammer _might_ have an evaluation criteria concerning the "openness" of the file/data formats but they will be making their decision based on the functionality.

IMO, the people who choose the system (PMs) will evaluate it on the functionality. The IT folks need to bless it and their concerns are related to network security, integration, etc.

Once you decide who you are going to sell to then you'll know what to emphasize.

Unfortunately, the product needs to be sold to everyone. The functionality for the end user has already been considered and will be very attractive. The back end is an either-or option at this point and makes no difference to the functionality, but could make a difference to IT/corporate for the issues outlined above.

Bernard Ertl
eTaskMaker project planning software