Business Central Projects: Defining Projects and Project Tasks
- Ken Sebahar
- May 5
- 5 min read
Every organization will at some point face new projects that must be completed in order to maintain the long-term success of the organization. Whether these projects are internal projects or customer-related projects, they must be well-planned, properly budgeted, and accurately tracked to ensure that these projects don’t result in lost productivity, reduced morale, or lower profits. By their nature, projects are unique undertakings and therefore disciplined tracking and reporting are required to keep these beasts under control.
The Microsoft Dynamics 365 Business Central Projects module (formerly the “Jobs” module) can be a very powerful force in improving how your organization plans, manages, and tracks the operational and financial results of your various projects. The Projects module provides the structure, integration, reporting, and financial management controls to effectively manage a wide variety of projects or jobs.
Key to unlocking this power is fully understanding the capabilities of the Projects module. Specifically, understanding how transactions are processed throughout the system and how other modules within Business Central are integrated are required to ensure that everything has been set up in a way that will best fit the processing and reporting requirements of the organization.
The first thing on the Projects to-do list when implementing Microsoft Dynamics 365 Business Central is determining if the Projects (formerly “Jobs”) module is a good fit for managing your project-related activities. Making this determination usually requires a detailed requirements gathering session with a seasoned Business Central consultant who understands not only the Projects module, but also most other areas of Business Central including Manufacturing, Service Management, Warehouse Management, Inventory, and Financial Management. For how could one properly determine that the Projects module is the best fit when the other options available aren’t fully understood and communicated to the user team? Are you sure you are talking to the right person to help you make this decision? As obviously important as answering this question is, it is not the topic of this post, so let's proceed under the assumption that the Projects module is the best option.
The next determination to be made (and the primary focus of this post) is defining Projects and Project Tasks. Specifically, you need to answer the questions “What is a Project?” and the related question “What is a Project Task?”
I know, you may be thinking that defining your Project and Project Task structure should be pretty clear and obvious. But I can tell you from experience that most often it is NOT clear and obvious. There is quite a bit that goes into answering these questions, and usually a lot of trial and error takes place before an organization is happy with their project structure (sometimes referred to a WBS, or work-breakdown-structure).
Let’s review a relatively common scenario that needs to be processed through Business Central using the Projects module:
The sales team just received a purchase order from a new customer along with a deposit for $150,000.
Per this order, our organization will be engineering, building, and installing a set of 3 in-line manufacturing machines. This project is expected to take 6 months to complete.
Two of the machines will be designed and built by our Automation Products Division and the third machine will be built by our Environmental Products Division.
All three machines along with a list of additional parts and supplies will be installed by our installation team. Installation will include on-site machine certification and training, as well as a one-year warranty period on parts replacement.
All shipping costs, travel expenses, or third-party site preparation costs have not been included in the initial order and will instead be quoted, approved, and billed to the client on a time-and-materials basis.
Revenue and costs will be recognized as each machine is shipped.
The customer will be billed 15% up-front (the deposit), an additional 15% each of the next 5 months, and the final 10% upon certification of the machines.
So how many Projects is this? And how should the Project Tasks be defined in order to properly facilitate the required budgeting, cost tracking, billing, and cost/revenue recognition transactions related to this order?
Perhaps the answer is not that easy!
What you will find is that the mechanics of creating new Projects and Project Tasks is relatively simple. Even building out your Project budgets with Project Planning Lines and posting actual transactions against Projects is intuitive and straightforward. But you will likely find that the decision of how to define a Project and its related Project Tasks ends up being the most time-consuming and difficult part of the Projects implementation. This is particularly true when the WIP Method field is being used to calculate revenue recognition and cost recognition since how the Project and its related Project Tasks have been defined can have a significant impact on how the Project activity flows into the financial statements each month.
As proof that defining your Project/Task structure is not easy, in most deployments of the Projects module, there is usually some level of modification or enhancement to the Project structure after the initial deployment. Sometimes these post-deployment changes to the Project structure is done strategically in order to ensure that users are not initially overwhelmed by the level of detailed Project tracking that is required. But sometimes it is because users need to see actual projects running through Business Central to fully understand the impact of some of the decisions that were made.
The good news is that this strategy of starting simple (or “crawling”) and expanding the use of Projects in the future (“walking” and then “running”) is relatively easy to manage. While you may need to stick with the structure that was initially created for the first few Projects through project completion, you can change the approach for how Projects and Project Tasks are created at any time as new Projects are created. This flexible nature definitely takes some of the stress out of the implementation and initial deployment, but be careful as it also could provide the user team with an excuse to not complete the required amount of “trial-and-error” testing prior to deployment.
Ideally, the majority of the trial-and-error phase is completed during the implementation and prior to deployment, but this is not always the case, and it is for a variety of reasons. These reasons can include a lack of any clear starting point for defining the Project/Task structure, users who do not put in the time needed to fully cycle through multiple entire Projects as part of training and testing, or poor guidance from the implementation team assisting your organization with the project.
The good news is that the Business Central Projects module is well-equipped to handle all of the requirements defined in the scenario presented above. Understanding how your organization will setup and manage all of your unique project requirements via the Project and Project Task structure is the key to maximizing your overall return on investment, optimizing your team's efficiency in tracking and reporting against Projects, and ultimately improving your organizations profitability for years to come.
Commentaires