Thursday, September 03, 2009

Subject to interpretation


After obtaining a copy of the RFP and reading it, I have to say I don't agree with the interpretation of the requirement I offer the following points:

1. The rfp states that the contractor will "provide" a CMS. It did not say the contractor has to "own" a CMS or have a proprietary solution. "Provide" seems to be the operative word here. The contractor should have or possess the capability to "provide" this solution.

I don't interpret it the way you or MAS has. Furthermore, City Hall insiders say MSF does have a CMS solution to implement but it's up to the City and MAS to resolve it's issues regarding access to the website source code so it can be implemented.

This is the actual requirement wording, you be the judge:

9. Web Site Planning, Development and Maintenance
> Review existing CNO intranet and extranet sites.
> Develop recommendations and designs for future intranet and extranet site development.
> Perform web-site development using advanced portal technologies.
> Provide a Content Management Solution and work with CNO to develop a workflow to support independent content updates by departments.
> Upgrade current On-Base Document Management System to current version and design integrations with MOSS 2007.
> Design and implement core intranet site components such as knowledge bases, reporting portals, collaboration sites, workflow, executive dashboards, and corporate communication processes.
> Implement, configure, tune, and maintain enterprise search engines.

Also...we've got conflicting information from "City Hall insiders". I've been told MSF is negotiating with MAS to use their existing CMS...don't know if it's true but that is what I hear. So are you telling me that the MSF actually has a CMS but MAS is not cooperating with MSF to allow access to the database?


Geek said...

I'm an IT pro who has no links whatsoever to CNO (other than the general sense of nausea we all feel at seeing our taxes handed out as graft to Friends Of Ray). I have also been on both sides of many IT portal RFP's.

FWIW my professional read on the RFP requirement to "provide" a CMS is that it's clearly NOT a requirement for the bidder to own a proprietary CMS. In fact, you don't WANT the vendor to use a proprietary CMS because of exactly the kind of stuck-with-the-vendor problems we have with the MAS CMS currently. What you want is for your vendor to deploy a COTS CMS, not re-create the wheel by building a system when there are many existing commercial products.

So while I admire and applaud the great work AZ does...and there may be other things that are fishy with the new contract...I think this particular item is a non-issue.

I want to know more about the land grab going on in Algiers! That reeks.

Anonymous said...

AZ you have it right on the head this time yes NSF does have a CMS and MSF is blocking the access. We should applaud MSF not critize them. I would not get in bed with MAS if my life depended on it.

Anonymous said...

The point about not wanting a propriatory whosit so that you don't end up over a barrel makes sense to me. Thanks, poster.

I second you re: land grabs, and I hear you, Zombie, but I don't know what to do about that yet.

Ray said...

Provide a Content Management Solution and work with CNO to develop a workflow to support independent content updates by departments.

I've worked for software ISVs for 20 years, and this doesn't read like they were required to own a CMS and provide it. "Solution" is a term of art in the industry...all it means is that at the end of the day, they have implemented some kind of CMS, whether by implementing based on a proprietary one of their own, bringing in some Vignette or Interwoven licenses and building it on that, or writing a shitload of Perl scripts on top of the existing SQL.

"Solution" != software. Solution is the whole package, and software is just one of the details.

Anonymous said...

I think y'all gettin bogged down in da details. It don't matter if ya OWN the CMS or RENT the CMS or use open source. the product "lock-in" occurs at the DATABASE side.

Any product is gonna be designed to use its own database table schema, stored procedures, functions. No matter who you switch to, they won't match up!

I gar-run-tee!

To avoid lock-in, you have to be ready to say "fuck it" and switch to the new system, converting any data you absolutely need along da way.

Dat's it. Could, can and WILL happen to anyone using any system. There's NO gettin' around it.

It's all about the data, duh.

Gotta hope da new boys took this into consideration and planned accordingly.

Anonymous said...

This appears to be a clusterfuck.