How Imaginet’s Business Productivity Practice Delivers a Project

How Imaginet’s Business Productivity Practice Delivers a Project 

Hi everyone, my name is Jesse Dyck, and I’m the Practice Lead and Principal Consultant for Imaginet’s Business Productivity Practice (BPP). We generally deal with all things Microsoft 365 (M365), from SharePoint to Teams, Power Apps to Custom SharePoint Framework Web Parts; we do it all. In this blog post, I wanted to walk you, a hopefully potential customer, through a rough idea of how my team delivers a project. There are many different types of projects, from migrations, Intranet builds, process automation, and even fully custom development for features that M365 doesn’t capture. But today, I will walk through the simplest one, a single process automation project. This could be a process that already exists or a new process being developed at the client. For our purposes, let’s assume that it’s a process already existing. Let’s get started.

Now, at this point, the project kicks off. I’ve generally already met with key project team members (owners, stakeholders, etc) via the pre-sales process. During project kick-off, you get to meet the rest of the members of my team assigned to your project and our Engagement Manager. The Engagement Manager will be your main contact point for setting up meetings, discussing project status and budget burn, that sort of high-level project info. Through me, you’ll be introduced to at least a Project Lead, and depending on the size of the project, an additional consultant or two. By the end of the Kick Off Meeting, we will have defined or started to plan the following:

• Access for the team members to the client environment
• An overview of the project and what we are going to deliver
• A weekly status call, and a scrum meeting cadence (dates and times for both)
• Who our point of contact is with your team
• If there are any immediate scope changes based on our understanding of the project

Next up is discovery and analysis. My team will, via workshops with the client team, and investigation of the environment and requested features, determine the best way to solution and deliver the project. Some of this is decided up front during pre-sales, but here is where any theories are tested and ensured to be true, or a new path is found. Deliverables out of this phase are usually an Information Architecture (a blueprint of what we plan to build within SharePoint to support the solution), and if there are any Power Apps or Flows, mock ups and diagrams of the App or process. Other artifacts may be needed or requested, and this is decided on a case-by-case basis. Via a Requirements Sign Off document, we gain acceptance of the plan, and sign off that everyone understands what we are trying to build. Next up is development.

Development is simple from a high level, and very complex lower down. At a high level, what you will see is status reports during scrum of what we are working on, how its going, and if there are any blocking issues that need to be resolved. During weekly status meetings, you’ll be updated on progress, project state, budget burn etc. to understand how the project is going. This meeting could include demos, but usually we have separate meetings to discuss and review work. This happens iteratively until the development is completed, tested (by our team and the client), and documentation and training has been completed.
All that’s left is to close out the project and discuss any lessons learned both with the client project team and internally and deliver any final copies of project artifacts required. That was a general project overview. As you can see, its not that scary, and we’re here the entire time to help guide you to the end. Hopefully you’ll join as a client one day and you’ll be able to see the fantastic guidance and work my team will deliver for your company. Until then, thanks for reading.