Those of us who've been around Project Management and ITBM long enough are well acquainted with the ms project import utility:
ServiceNow is very careful to advise us of the limitation of an MSProject import, but the fundamental weakness of this tool is its inaccessibility. It is precisely because the import is so limited that it's code should be deployed in the platform like all other components, and not hidden in inaccessible depths.
Why does hidden import code adversely effect ITBM implementations?
1) Every serious PMO will want to import projects
2) PMOs tend to be more open to straddling multiple tools, but not over years.
3) Serious PMOs can have projects that span years (see 2)
4) The gaps between SN and MSProject mean different customers will address the gaps differently.
5) Reasons 1-4 mean each implementation may require special import protocols.\
Leveraging the Community
There are clear benefits to creating a visible (and editable) MS Project import codebase. The chief advantage is democratizing the power. I guarantee you, with the small number of partners currently dedicated to ITBM, the Import Tool could be improved farther in 6 months than in a year or more at mothership alone. Not taking anythign away from the ITBM team... its just that those of us in the field will see more scenarios (and do the hard modification work) more often.
6 Comments
