Beware the SharePoint MVP!

 

No, I am not going to bash the SharePoint Most Valuable Professionals! I have received help, feedback and support from many MVP’s including Veronique Palmer, Jasper Oosterveld and Gregory Zelfond, and I have read and used the posts and presentations of many others.

But I am glad this title caught your attention 🙂

The Minimum Viable Product

This blog will be about another MVP – the Minimum Viable Product, a common word in Agile development, meaning you will launch a product that meets the basic requirements (as defined at the start of the project) and will be improved incrementally over time.

I think I have been woking somewhat agile  when I was configuring solutions, and met with my business counterparts on a very regular basis to discuss the proof of concept/prototype and checked if this met their expectations.
I only created a very small list of requirements, as I knew that many business partners only had a vague idea of what they were really looking for, and when confronted with my interpretation of their requirements all kinds of unexpected, or in any case, unspoken, things came up.

  • Is there an option to leave this field blank?
    Yes, but that means that we either leave this non-mandatory (which may lead to more blanks than you want) or we add a dummy value such as “please select”. What do you think is best?
  • Can we have a multiple choice for this field?
    Ofcourse, but that means you will be unable to group on this in the views, so we will have to resort to a connection for filtering. Oh and then it is better to make this field a look-up field instead of a choice field. Let me rework that.
  • What if someone forgets to act on the email?
    We may want to create a view that allows the business process owner to see quickly which items are awaiting action.

And more of those things. I generally met with my business partner once every fortnight, if not more often.

So I am all in favour of especially the short development cycles of Agile.

“Users” does not mean “end users”, exclusively!

I also think that “user stories” are much more realistic and human than “requirements”, although they sometimes look a little artificial.
By the way, I would recommend any team to think not only of “end user stories” but also of “tenant owner” stories or “support user stories” as other people involved have their own needs or requirements.

Rapid improvements

I also like the idea of launching a Minimum Viable Product and doing small, rapid improvements on that, based on feedback and experiences, because

  • You can show users that you are listening to them
  • You can show that you are not neglecting your intranet after launch
  • It gives you something new to communicate on a regular basis
MVP-DevelopmenttoLaunch
During development, you work towards the Minimum Viable Product

So, when we were launching our intranet I was quite interested to be part of the project and to work towards an MVP.

When we finally launched our MVP we also published the roadmap with intended improvements, and shared the process of adding items to the roadmap.  That way users could see that we had plans to improve and that we would be able to spend time and attention on meeting the needs of the business.

Vulnerabilities

When launching an MVP with a promise to make ongoing improvements you are more vulnerable than when you do a Big Bang Launch & Leave introduction. What about the following events?

  • Cuts in the improvement budget.
    Those can be a blessing or a curse, but they may happen.
  • People who leave before they have documented what they have created.
    I have never liked the extensive Requirements Documents and Product Descriptions that go with traditional development, but if you are handing over your product to the Support organization, you really need documentation of what you are handing over. End users can have the weirdest questions and issues! 🙂
  • Reorganizations which turn your product team or even your company upside down.
  • Microsoft changes that mess up your customizations. We have a webpart that shows your Followed Sites – it suddenly and without warning changed from displaying the first 5 sites you had followed to the last 5 sites. Most annoying!

So before you know it, you end up with a below-minimum viable product. ☹

MVP-Developmentfromlaunch
While in a normal development cycle you would slowly and steadily improve upon the MVP, unexpected events can leave you with something less than MVP.

What can be done?

So before you start singing the praises of Agile development and put on your rose-tinted glasses

  1. Make sure you have a safe development budget that can not be taken away from you.
  2. Ensure you have an alternative no-cost optimization plan, such as webinars, Q&A sessions, surveys, configuration support, content changes etc. to make the most of the launch of your MVP and to get feedback for improvements for when better times arrive.
  3. Insist that everyone documents their configurations, codes, processes, work instructions etc. as quickly as possible. It is not sexy but will save you a lot of hassle in case your team changes.
    If you are in need of extracting knowledge from leaving experts, here are some tips for handing over to a successor, and some tips for when there is no successor in place yet.
  4. Be prepared for changes in processes, data or organization. You do not have to have a ready-made plan, but it is wise to think about possible implications for your product or process if the Comms team is being reorganized, someone wants to rename all business units, or you need to accomodate an acquired company in your setup.
  5. Keep customizations to a minimum. Use existing templates and simple configurations.
    Personally I would be totally content without a customized homepage. The SharePoint landing page or, even better, the Office365 landing page as the start page to my day would work perfectly well for me, but I have learned not many people share that feeling.

Any experiences to share?

Have you had similar experiences? Have you found a good way to handle budget cuts, a way to develop budget-neutrally, how to deal with people changes or another way to deal with unexpected events that endanger your MVP? I am sure there are many people (including myself) who would like to learn from your stories!

Images are from Simon Koay’s totally gorgeous Superbet. Look at that B!
M=Mystique, V=Venom, P=Poison Ivy

Advertisements

4 thoughts on “Beware the SharePoint MVP!

  1. Veronique Palmer March 29, 2018 / 12:09 pm

    Hehe, thanks for the shoutout Ellen. Another great blog as usual.

  2. Erik in SD March 30, 2018 / 5:36 pm

    I love the inclusion of “tenant owner” stories or “support user stories” in the user story collection. That can really be a time saver down the road.

    • Ellen van Aken March 30, 2018 / 5:42 pm

      Thank you, Erik! So you think these stories are not common? Hmmm…I may have invented something 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s