In Winter 2015, I decided to fulfill a long-term career goal of attaining the Project Management Professional (PMP) certification. Although different for everyone, my own reasons for wanting to become PMP certified were (in order of importance):
Learning. Studying for and passing the PMP exam would require me to learn a significant amount about project management, and in particular the methodologies, tools and techniques detailed in the Project Management Body of Knowledge (PMBOK).
Challenge. The reputation of difficulty in attaining the PMP attracted me to successfully achieving it.
Career development. As a functional and project manager, the PMP designation would increase my skills with my employer, and provide both company and personal legitimacy when interacting with customers and external stakeholders.
In September 2015 on my first attempt, I successfully passed the PMP exam with “Proficient” in 4 out of 5 process groups: Initiating, Planning, Executing, Monitoring and Controlling, and “Moderately Proficient” in the last process group, Closing.
My objective with this post is to detail how I used agile project management methodologies to successfully study, and pass, the PMP exam in the hopes that someone else finds this approach useful in their studies.
It wasn’t all that long ago that Googling “SharePoint Alternatives” didn’t yield many results. Sure, you’d get listings like Dropbox, but SharePoint is so multifaceted that saying Dropbox is an alternative is like saying a baseball is the same as an apple – similar shape, but totally different purposes.
Fortunately, a lot of companies have made the jump into direct competition with SharePoint, offering not only file-sharing, but blogging, wikis, shared calendaring, and the ever-present social networking as well. This is great news not only for people looking for alternatives to SharePoint, but also to SharePoint itself, who I firmly believe could use a little more competition to help spur innovation and healthy competition – after all, “No Pressure, No Diamonds”. SharePoint proponents often bash the alternatives out there, but I never understood this mentality; the best tool for the job is the one that you’ll use the best, not the one someone else says is the best. Below is my take on Igloo, but ultimately you’re going to have to decide for yourself if it’s the right tool for the job you have in mind.
The Skinny On Igloo
Service: Cloud only.
Cost: Free for teams up to 10 people, $12/ user/ month after that.
Igloo is making some impressive inroads against SharePoint, and has won such customers such as Harry Winston, Mobilicity, Deloitte, The Keg, and The Co-Operators Insurance. Interestingly, it also counts several healthcare organizations in its roster of clients as well: Ontario Health Quality Council, Mental Health Commission of Canada and the American Psychological Association; these are interesting considering how shy healthcare IT can be towards cloud-based services.
Built by the Canadian company of the same name, Igloo offers a collaboration solution separated into Apps. Each app represents a discrete function that integrates with other Igloo apps to produce the entire Igloo system. The default apps are: Blogs, Calendars, Files, Forums, Microblogs (ie: Twitter/ Status updates), Wiki, Rooms (like sub-Igloos), Pages, and People. You can choose to leave the default apps as-is, or you can rename, remove, or add them as the needs of your team evolve; Igloo offers quite a bit of flexibility without the need to delve into code or obscure configuration screens.
From the get-go, it’s apparent Igloo has put a lot of time and effort into getting a slick and accessible design in place. The application itself looks great: modern and unobtrusive, it knows you’re here to do work and for the most part stays out of your way. The thing I like about Igloo is they seem to understand how to provide a default structure and design that lets small to medium teams get started entering and sharing information early and easily. Many collaboration applications give you a blank canvas, which can be great, but also daunting from a “Where do I even start?” perspective.
Get A Room Already
Igloo Rooms allow for a kind of sub-igloo for a particular team or project, giving that team their own forums, blogs, wikis, etc. that is separate from the larger company. The Room’s home page displays a stream of microblog updates by the team/ project members, making it quick and easy to stay abridged of what others are doing. Project Rooms also incorporate milestones for a project planning lite experience; this isn’t full-on Microsoft Project, this is bare bones project management (and for some that’s enough). On the whole, Rooms appear to be a more effective implementation of what SharePoint calls “Team Sites”, which are the mainstay of many SharePoint deployments.
The Igloo mobile app (available for Android and iOS) while not great, is certainly ahead of a lot of the clunky 3rd party SharePoint apps available out there. The app itself exposes all of the er, uh, apps available in your Igloo in a clean and well designed interface. Navigating through your igloo and finding content is straightforward and easy, as everything is already structured and well categorized in the various apps available.
Unfortunately, the mobile app is really about consuming content already available from your Igloo, and not so much about producing content on your mobile device. At the time of writing I could not find a way to add a file to a file app or edit a wiki or blog entry. The only means of content creation is to create a microblog post, which is fine for status updates, but if a client sends me an email with an attachment and I’m on mobile, it would be great to have a way to actually share that file in the igloo without having to wait to get back to my office.
When I first tried Igloo, I could not get the search to work – at all. Creating an article and subsequently searching for it yielded no results. When I tried it again some time later, search did find the articles and it was accurate, leading me to believe that much like SharePoint, the search indexer executes on a schedule, so expect to wait a while for changes to be reflected; in some cases, it was upwards of 30 minutes to an hour for my changes to be shown, and this is just too long. Search is the cornerstone of any collaborative application, and Igloo’s weakness here is a significant one.
No Wiki Markdown
Another annoyance is that there does not appear to be any kind of wiki markdown, meaning new pages and links must be made by clicking through the UI, rather than inserting a few characters (ie: [[This would be a link to another page]]). For someone that spends a lot of time in wikis, this was a big disappointment, and it means my time gets wasted clicking around instead of producing content.
Despite the excellent design and structure, there are some real oddities to be found in the UI: The biggest one being that the WYSIWYG editor looks like an old stock MCE Editor. Cramped button spacing and default icons are a stark contrast to the super-clean and modern UI. It’s a small blemish, but one that really stands out in the polished look Igloo has cultivated.
Finally, and this is a regional gripe – I cannot tell my American colleagues that “the file’s in Igloo”. Can’t do it. Nope. As a Canadian, saying this phrase is tantamount to wearing a sou’wester while holding a Tim’s in one hand and a picture of the Queen in the other and saying “Aboot that file..” (FYI we don’t actually say ‘aboot’). I get what Igloo is trying to do with the name, but as a Canadian, the chuckles I get from Americans even mentioning the word ‘igloo’ are a bit much. Maybe they could have called it Beaver Lodge, or Much Ado Aboot Files (no – wait, those are terrible ideas, Nik).
Would this prevent me from buying Igloo? Absolutely not. But as a Canadian I can’t NOT make an igloo joke when given the chance, right?
Igloo is great software, and being free for 10 people or less makes it a perfect option for small teams.
The design is stellar and easy to use, save for a few small gripes about the WYSIWYG editor.
Mobile App is ok, but room for improvement
Search issues I encountered were frustrating, and it would be great to see results showing up faster than 30+ minutes after being added.
No wiki markdown is a hard pill to swallow for me, and should be for anyone who spends a lot of time producing and organizing wiki content
Recently I accepted a new position as a Software Development Manager, not working with SharePoint; this is an exciting new challenge for me, as I’ve been fully immersed in the technology for some time now. I started working with SharePoint at IBM 5 years ago, and since then I’ve worked with various deployments pretty much coast-to-coast in Canada, from Vancouver to Ottawa to Halifax. I wanted to make a post reflecting on 5 years of working with Microsoft SharePoint, and discussing at a high level some of the observations I’ve made of the various SharePoint deployments I’ve worked on over the years in order to help others understand what makes SharePoint a success (or failure).
“Governance uses people, process, technology, and policies to define a service, resolve ambiguity, and mitigate conflict within an organization.”
― Joel Oleson, 10 Steps to SharePoint Success
Governance has always been a hot button topic in SharePoint, and will be for some time; in my opinion, lack of Governance is one of the primary sources of frustration and failure for every SharePoint deployment. This conflict is tragic, because at its heart Governance is the simple act of planning and setting expectations, something which everyone acknowledges must be done, but all too often do not actually do.
For many organizations, Governance is the opportunity to take a moment before implementation and actually think about:
How do we intend to use SharePoint?
What are the limitations of our SharePoint deployment (technical, human resources, knowledge, or self-imposed)?
Are there legal implications we must adhere to, and how do we do that in SharePoint?
What specific challenges will be addressed by specific features of SharePoint?
What are the expectations for the various stakeholders (Executive, IT, trainers, end users, etc)?
#5 is a big topic, because this is where a lot of conflict comes into the organization. At some point, someone will think it was someone else’s job to fix/ prevent something bad that happened, and if you don’t have some kind of written policy or process, you’re asking for a round of the Blame Game, and that’s just poison in any organization.
A common objective when deploying SharePoint is “increase collaboration and communication”, “provide document sharing”, “use SharePoint as a development platform”. I would argue that these aren’t objectives, they are aspirations, because they are exceedingly difficult to measure through hard data (user surveys are difficult to count), and they represent broad, amorphous goals. Sure, there may be 400,000 documents in SharePoint, but that’s a storage metric, not a collaboration metric that indicates how, when, and if people are actually using those documents and to what effect. How can you measure if someone is communicating more effectively? Perhaps you could infer that by seeing that people are performing more work in shorter periods of time, but maybe that’s just the espresso machine you installed last month.
An objective is something that can be measured, well, objectively, and contains two critical ingredients:
What you are trying to do
What will tell you that you did it
Good examples of objectives are: “Use InfoPath, SharePoint, and SharePoint Workflows to reduce TPS-421A form processing time from 5 days to 3 days.”, or “Reduce meeting minute approval time from executives from 20 days to 10 days”.
Objectives can be on the micro-scale, but tie into the broader strategy of SharePoint as defined by your Governance. As objectives are met, those successes should be celebrated, and similarly if objectives are not met, those failures should be analyzed, lessons learned, and finally addressed; either way, there must always be new objectives developed and added to the list.
Simply put, if something cannot be measured, it cannot be managed. If a system – any system – SharePoint or otherwise – cannot be managed, then you have real and serious problem on your hands.
Make the Technology Work for People, Not the People Work for Technology
There’s a common saying among a lot of SharePoint admins I’ve worked with that people have to learn to do things “The SharePoint Way”. I spent much of the early part of working with SharePoint trying to get people to change how they work towards The SharePoint Way, with mixed success. Sometimes people have been doing a process for 5, 10, or even 15 years, and they’ve seen technologies like SharePoint come and go. You can’t expect to make people’s processes change overnight, particularly if they haven’t been sold on SharePoint. When I started to see real success, it was because I accepted that people have a process that can be fit into SharePoint, and that SharePoint can be adapted to fit people as well – in essence, finding a middle ground between people and technology.
When you start showing people that what they do can work in SharePoint, and often much more efficiently than without SharePoint, you not only make people more productive, you often find internal champions that are willing to promote and teach others when SharePoint administrators aren’t around.
It’s an exciting time for SharePoint and Microsoft. SharePoint, like so many other services and applications, is jumping headfirst into the cloud. Yammer stands to change SharePoint in a fundamental and overwhelmingly positive way. With Steve Balmer leaving the big chair, and other leadership changes at Microsoft, there are some great opportunities for positive change and development – particularly in the cloud and mobile arenas.
While I may not be working with SharePoint day to day as I have been for years, I look forward to seeing how the technology changes over time and continues to meet the challenges of the various organizations and businesses that deploy it.