Why do SharePoint projects cost so much? Why do organizations get sticker shock when they see the cost of, say, a cool new intranet, or a migration of SharePoint to the cloud? Sometimes, the project starts off fine, but then shock comes later — when the budget is mostly gone — and the team discovers a ton of work that still needs to be done. If you need to manage the cost of your SharePoint project, or squeeze your project into a tighter budget, read on. I’ll describe five strategies for keeping the budget of your SharePoint project under control.
Granted, some projects suffer from unrealistic expectations. Other projects are simply mismanaged. As a senior consultant, I have seen every combination and permutation of these challenges. Rather than dwell on the obvious, this post addresses teams with reasonable expectations, reasoning skills, and reasonable experience. Even with reasonable expectations, skills, and experience, there are still risks that costs could rise out of control. The strategies described here will mitigate risk, improve results, and help you keep expenses down.
Name a Product Owner
Name a Product Owner of your SharePoint project, and give them authority to set the priorities.
The Agile Scrum framework defines the Product Owner as “a non-coding team member who has a complete grasp of the requirements and business value of the product and is responsible for prioritizing work for the team.” In the context of a SharePoint project, the intranet, extranet, or application you are building (or migrating) is the Product. Even though most SharePoint projects are managed using waterfall techniques rather than Agile, you can still adopt the concept of Product Owner and you should.
SharePoint and the Microsoft 365 environment are packed with features and are changing fast. Likewise, business requirements for your intranet are likely numerous and are also changing fast. Find a Product Owner who understands both what the platform can do, and what the business needs. Give that person the responsibility and the authority to hold the line.
Scores of decisions will need to be made before your project is done. Even migration projects where you are “simply” moving an intranet from, say, SharePoint Server 2010 to SharePoint Online can take on a life of its own. Stakeholders and power users start to see all the cool things they can get in Microsoft 365 and start to insert (“clarify”) requirements for their sites. A strong Product Owner can be the one ring to rule them all. Even with a pretty good specification going in, you will still face countless trade-offs before you are done. Your Product Owner understands that every decision represents a risk of increasing cost.
Promote Out of the Box Features and Minimize Customizations
SharePoint Server, SharePoint Online, and Microsoft 365 come with a broad and deep range of features out-of-the-box (OOTB). They also have many powerful APIs and extension points for building custom solutions and integrations. If you are on a shoestring budget, promote the out-of-the-box features and discourage the customizations.
Between OOTB, on the one extreme, and custom solutions, on the other, lies configuration. Configuration is a grey area. I generally encourage enhancements through configuration as high value for low cost.
The following table lists what I consider to be OOTB functionality in the left-most column, customizations in the right-most column, and configuration features in the middle column (between those two extremes):
Generally, the more you can stay to the left in this table, the simpler your solution and the less costly.
What about PowerApps and PowerAutomate (formerly known as Flow)?
From the perspective of a tight budget, I consider PowerApps and PowerAutomate to be customizations. These are terrific tools and you absolutely should use them — if your project needs this kind of functionality. But PowerApps and PowerAutomate will cost you more than a basic SharePoint list will cost. Don’t underestimate the cost and scope of building a custom PowerApp. Your team needs the skills of a power user bordering on a software developer to build anything more than a trivial PowerApp. Moreover, building the solution is just the start: consider the lifetime cost of the solution. Maintenance and support of these features will cost much more than OOTB and special configurations.
Rapid Application Development (RAD)
Each time your users request a special feature, try to meet their needs through the configuration of out-of-the-box functionality. You can do quite a lot through the configuration of the out-of-the-box features, and yet, users always seem to want something slightly different (or very different) than what you show them. Try to persuade them to start with OOTB features and features they can get through configuration. If, after exhausting all the configuration options, SharePoint still can’t do what your users need, then consider Rapid Application Development (RAD).
Keeping the limits of your budget firmly in mind, put a Subject Matter Expert (SME) together with your SharePoint/MS365 developer or consultant. Have them do rapid, iterative prototypes. Challenge them to see just how far they can get with the least amount of complexity. Complexity grows the farther your solution reaches to the right side of the table of OOTB-vs-Customizations shown above.
The goal of the RAD approach is to discover the least complex, most cost-effective approach that meets user’s needs. Another Agile concept is highly applicable here: the concept of the minimum viable product. What minimally complex solution will meet the needs of your users for the next six months to a year? If they can settle for this, it won’t bust your budget, and you live to fight again another day. In other words, you can finish your SharePoint project “within budget” and leverage your newly earned credibility to win a new budget for a Release 2.0 that goes back and improves on some of the things you compromised on in Release 1.0.
Reduce Calendar Time
Time is money, especially when you are paying a development team. At the same time, moving fast increases risk; haste makes waste. Between the one extreme of snail-pace, and the opposite extreme lightning, there is a sweet spot. The precise cadence must be discovered anew with each project you run. As a consultant, I know I must sometimes pace myself down to a pace at which my client can receive and absorb my work. Testing takes time, and communication takes even longer.
A good project manager learns quickly where the sweet spot is for the project at hand, the team, and the customer. When there is a range of velocities that could potentially work, those that bring the solution to completion sooner will save money, all else being equal.
When the pace is so slow that your developers are only working a fraction of their day on your project, there is the hidden cost of context-switching. Each time your SharePoint expert turns to your project, they must remember where they left off, locate their notes, and find the right passwords.
For every day or week that goes by, there will certainly be another status meeting. Fewer weeks equals fewer status meetings. Just don’t add lots of additional staff in an effort to shrink the elapsed time of the project. As shown in the classic book, The Mythical Man-Month, (Fredrick P. Brooks, Jr., Addison-Wesley, 1975) adding staff incurs coordination costs and quickly becomes a negative return on your investment. On the other hand, large, complex projects where there are multiple threads that must go forward in parallel are well suited to having a team with multiple developers. A basic SharePoint migration to the cloud, however, is often best with a small team of, say, one senior technical expert, one fractional QA, and a fractional project manager.
Go Offshore – But Be Abundantly Clear with Offshore Development Teams
Leverage the lower cost of technical experts located in India, China, and other tech-savvy parts of the world, but be abundantly clear on the requirements, constraints, expectations, and technical details of what you are asking them to do.
Leveraging an effective international team can go a long way towards delivering your SharePoint project on a tight budget. Almost every project I work on involves a mix of on-shore and off-shore resources. The hazards to take precautions against stem from the fact that your offshore team is half a world away. Realize that what seems obvious to you when you send them an email may be confusing, vague, or ambiguous to them.
When communicating with offshore technical experts, a working prototype is a great way to express the direction they need to go. Written specifications are important, too, but you must include screenshots, wireframes, and specific user scenarios.
In addition to the written and on-computer forms of communication, I strongly recommend meeting in real-time. The time zone difference means someone, or everyone will be meeting at an inconvenient time, so share the pain equally. I work in Seattle (Pacific time zone) and I find it works well to have a longer, more technical design meeting that starts at about 9 PM Pacific time (about 9:30 AM in India) and a shorter, more status-update type of meeting at about 8:30 AM Pacific time (about 9:00 PM in India). That way the deeper, technical material can be covered when my offshore team members are fresh and starting their day, and the quick status update comes when they have finished their day and I can find out what they got done.
Conclusion
SharePoint/O365 is complex, but projects don’t have to cost too much. With a strong team, a good Project Manager, and the strategies described here, you can deliver a great solution without breaking the bank.
Martin Cox is a Senior SharePoint Architect at Affirma.
Comments are closed.