Iyfjky

Question

A web department develops a lot of CMSes using developer-friendly tools and frameworks, mostly using open-source technologies.

They are being asked to develop and support a website using Sharepoint to meet proposed IT-defined requirements at one of their large, enterprise customers. They are capable of developing in the Windows stack, but don't want to use Sharepoint because it's not developer-friendly and isn't even appropriate for an externally-facing marketing website CMS. They are familiar with the rich anecdotal history of Sharepoint cost overruns and limited ongoing feature development.

Narrowly, this is a question about the most developer-friendly CMS that tends to satisfy these checkbox-ticking IT departments. But the broad workplace question is: how can developers supporting marketing most effectively communicate to feature-checklist-obsessed IT decision-makers the potential cost of developer-unfriendliness and maintenance overhead in a large tool like a CMS?

Please substitute whatever phrase is the equivalent for you of 'enjoyable, productive, profitable technology choice.' — Apr 29 '15 at 22:17
I would say that you have to ask IT decission makers the list of checkbox tickers and evaluate the costs of the most promising technical alternatives. Decision makers do not care if you like the tool or not (it is why they are paying you), they care how much it will cost. If you can justify that an alternative will cost less, explain it. Show them how SP works in Chrome, Firefox, or Android — Apr 29 '15 at 22:20
I'm voting to close this question as off-topic because this question is not about navigating the workplace as described in the help center. — Apr 30 '15 at 13:19
Please don't. The question should be allowed because it has inspired an excellent "how" answer (blankip's.) See the section on constructive questions near the bottom of workplace.stackexchange.com/help/dont-ask — Apr 30 '15 at 13:23

score 4 · Answer 1 · 2015-04-30 01:51:36Z

I feel qualified to answer this question as a long-time development manager who has partnered with marketing departments in four different organizations to build similar systems. That said, you may not like my answer, but it's one that you need to hear.

This question does not appear to consider the needs of the business user at all.

App development is not an end unto itself. If you're developing line-of-business apps, you're doing that to meet a business need. What you call "checklist-obsessed IT decision makers" are people that are trying to find solutions to specific business problems. They probably don't care overly about your dev team's personal preferences, and why should they? Put yourself in their shoes - would you care? From their perspective SharePoint may be "marketing-friendly". And they're the end user. Whose opinion matters more?

Your question comes across as very condescending toward your client's Marketing and IT departments, and if you're approaching the engagement with this attitude, you're not going to make much progress. If you think the platform needs to be product X instead of product Y, and they seem to prefer product Y, you need to explain to them how it benefits them to choose product X. Maybe you think product X will be easier to maintain - to them that means that you can deliver new features more quickly. Sell that.

You'll have much better success if you try to partner with your client's Marketing and IT departments to make the best decision and avoid the phrase "developer-friendly" altogether.

Thank you. Just to clarify (but not detract from your main point), it's marketing vs. IT, not devs vs. marketing and IT. The third-party developers support marketing and are being asked by marketing to somehow divert IT away from making SharePoint mandatory. — Apr 30 '15 at 3:52

blankip 19.9k74781 · Answer 2 · 2015-04-30 04:46:51Z

I have been in the CMS/LMS world for 10+ years. I create a lot of custom solutions that support usually 5-10K people in different sectors in our very large global. I have used at least 6-7 very large PHP open source CMS and heavily customize for what we do.

And yes we have Sharepoint. At every project beginning we have our Sharepoint and Jive rep come in and show that they can do this and that. Will get to this more in a bit.

So right now we have an initiative with all the sector VPs so that our whole company will be on ONE CMS. All of our sectors do very very different things. Apples, oranges, bananas, and watermelons. This project has a checklist in an Excel spreadsheet of over 150 different things. They weight each of these things and will supposedly add up the score and choose solution - whether it be vendor or internal - with highest score. Note that the chances of this project ever ending is very very low.

So I am the tech lead on the project. I feel that I am very well trusted and I am pretty realistic what our small dev team can do vs a vendor. Well 1 year into this project we have one vendor that has a model that isn't scalable to 5K content pieces let alone the 100K we will have in a year. And another vendor that we are bound into a current contract with that is so horrible that you wouldn't believe the stories about them (they change live code in the middle of the day, repeatedly and sometimes by accident).

This is because these vendors showed them some flashy things with great graphics and acted like everything would work magically.

The problem with the spreadsheet is that it only includes pluses. If you do something horribly (data relationships) there is no minus. This is the fallacy that upper management falls into. The bait is the most common type of CMS which I have penned the Algernon CMS.

The Algernon CMS is the CMS model where you put things in categories. People keep putting similar things in categories. At first the CMS isn't much. Soon it is great because the basics are easy to find - these are entered first. Then it has tons of stuff and is still really good. But... Then things get old and outdated, people put duplicate things in, or there is just too much (usually around 1-1.5 years on a heavily used CMS). And it falls over. They choose another Algernon CMS because the old one doesn't work anymore (sarcasm) and rinse and repeat.

Note that SE model is pretty much the opposite of an Algernon CMS. It's whole point is one piece of content for one question and has self cleanup mechanisms. Sharepoint is an Algernon CMS for sure. Maybe not the worst offender and definitely more scalable than most but it is really hard to make it really user friendly.

What can you do to choose your CMS?

Figure out what IT's motivation is. From your question it is probably the same as IT at my company. We paid a boatload for Sharepoint so we better use it for everything. Your first action is to present to IT the extra costs it will take to do things in Sharepoint vs. open source. Be brutally one sided because chances are you are underestimating (most costs are associated with code around UX not basic Sharepoint things). As IT if they are willing to foot the bill for the extra costs. They have to understand that Sharepoint is a sunk cost. Use it where it makes sense and let each decision be its own.

Scare the crap out of the upper management on the demos. Dead serious here. I was on the phone with the vendor and they showed us their PDF maker. They allow you to combine multiple pages of diverse content in one PDF to use for sales opportunities. Well it looked awesome on demos and upper management was stoked. Then I saw that everything but the text was using custom HTML. So the sales person combining documents had to be a web developer. I asked upper management how many sales staff where web developers. They said none. I said well expect to add 6-8 web developers on staff and expect a huge lag time before requested docs are available in this pretty way.

To further the last point. Lay out every issue on the table. Be brutal. Consider anything that you don't have explained to you is working in the worst possible way until it is vetted out. But be careful. If you like a solution, whisper its issues. You lay them out but they are not as big of a deal. This is the power you have as a developer.

You have to give them the user experience. The checkmarks only matter if it looks good and is easy to use. You don't know how many times I have seen a vendor show something really cool and management was like "Uh what the hell were they trying to show us" after the call. Because the vendor had no css/graphics around the new technology.

Share your opinion openly. You don't have to be mean about something but at least say what you want to the whole group. First others might be thinking like you and are waiting for someone else to bring it up. Second if you are trusted people may think that they need to step back and give more consideration to what you want.

In the end you have to show people how things will work. I did something a couple years ago that I thought I would never do - become mostly Wordpress. I lost too many battles using what I believe are superior CMS models because they lacked in user experience. Wordpress is all about user experience and it really doesn't do much other than categories or taxonomies out of the box. So I have to spend tons of time adding things in so it doesn't become an Algernon CMS (things get archived at intervals and our editors/publishers get lots of emails telling them to do things - and if they don't... archived). Is it easier for me to become a Wordpress shop for the small/medium CMSs I do? Yes because I can't code 30 "plugins" every time but I can find them for free in WP community or buy for $10.

Am I telling you to do Wordpress or Sharepoint? No. I am telling you that the end user wants something they like using. ANYONE can give a demo to show how easy you can find something. Almost NO ONE will understand what search algorithm someone is using in the background nor care.

You communicate with the checkbox markers by calling out the things that don't work and functionally show them how something would work in your alternative. If you are just shouting out promises than you better be really well trusted or it will never work.

This is excellent and a perspective clearly forged in the same types of situations as the one I'm asking about. Obviously the disciplines and tactics you mention are learned over time, but when a quicker ramp-up is required, do you think it's worth practicing voicing some of these objections and performing some of these code/feature/cost walkthroughs? — Apr 30 '15 at 21:24
If this is in a short time frame and you don't have history with the team then you need to show examples of how things work or don't work. Not in powerpoint but in full on examples. I mean you can load an open source CMS in a couple hours and have a bunch of search examples in another hour. I know it is annoying and as waste of time but it saves time in the long run. — May 1 '15 at 3:25

score 4 · Answer 3 · 2015-04-30 01:51:36Z

I feel qualified to answer this question as a long-time development manager who has partnered with marketing departments in four different organizations to build similar systems. That said, you may not like my answer, but it's one that you need to hear.

This question does not appear to consider the needs of the business user at all.

App development is not an end unto itself. If you're developing line-of-business apps, you're doing that to meet a business need. What you call "checklist-obsessed IT decision makers" are people that are trying to find solutions to specific business problems. They probably don't care overly about your dev team's personal preferences, and why should they? Put yourself in their shoes - would you care? From their perspective SharePoint may be "marketing-friendly". And they're the end user. Whose opinion matters more?

Your question comes across as very condescending toward your client's Marketing and IT departments, and if you're approaching the engagement with this attitude, you're not going to make much progress. If you think the platform needs to be product X instead of product Y, and they seem to prefer product Y, you need to explain to them how it benefits them to choose product X. Maybe you think product X will be easier to maintain - to them that means that you can deliver new features more quickly. Sell that.

You'll have much better success if you try to partner with your client's Marketing and IT departments to make the best decision and avoid the phrase "developer-friendly" altogether.

Thank you. Just to clarify (but not detract from your main point), it's marketing vs. IT, not devs vs. marketing and IT. The third-party developers support marketing and are being asked by marketing to somehow divert IT away from making SharePoint mandatory. — Apr 30 '15 at 3:52

blankip 19.9k74781 · Answer 4 · 2015-04-30 04:46:51Z