How Do You Decide if Project Documentation is a Need or “Nice to Have”?

by | October 19, 2017 | Business & Leadership, Project Management

As a project gets started, a question that always comes up is “What level of documentation do we need?” I know from experience that the further you dive in, the easier it is to let the project documentation slide. As you have deadlines to meet and additional scope slipping in it’s easy to focus just on getting the work done and thinking “I’ll get to the documentation later.” However, I also know from experience that “later” very rarely comes and the documentation that was skipped over never gets created or updated.

So the question is – how necessary is documentation? If you skip some of the documentation, does that really affect your implementation? There are a lot of successful implementations that haven’t documented 100% of the designs, changes, and decisions. However, I’ve experienced that skipping the documentation can cause quite a few problems.

Missing & obsolete documentation situations during implementations:

Reviewing decisions

Multiple discussions/meetings occur to re-cover decisions that were made previously. This usually occurs because another scenario comes up that causes questions to arise about why the process was designed a certain way or why certain configurations were chosen. It requires all options to be rediscovered and then discussed before usually arriving at the same decision.

Configurations are changed

Configurations are changed to accommodate a new requirement or process and all the sudden other processes aren’t working as planned. If the configuration is documented, it’s easier to know why it’s set up a certain way and what will be affected if it’s changed.

Scope of a modification has changed

Extra testing, rework, and discussions with developers are required when the scope of a modification is changed and the initial design document is never updated. Once you get to testing and are trying to reference the design to make sure you are testing everything, you run into situations where the solution doesn’t match the design. This causes a lot of confusion and a need to work with the developer and the people who designed it originally to determine if it’s not working the same because it’s a bug or because there were undocumented changes.

Keeping the team informed

Bringing other people up to speed on the implementation is more haphazard and more work. Whether it’s adding someone to the implementation team or just training users on the implementation, you have to bring them up to speed by memory and a lot of pieces are easily missed. While the basic processes are usually easy to remember, it’s sometimes difficult to communicate why certain pieces of the process are so important or why it was set up in a certain way. Also, if you are wanting users to take more ownership of their areas of the system and be less dependent on the original implementation team, it is a lot easier for them to do this if there is complete and accurate documentation for them to reference.

Lack of documentation for the future

Aside from the situations I mentioned above, the other impact that is usually forgotten about is the impact lack of documentation has on future implementations, upgrades, or even simple changes. While you are in the middle of your implementation it’s hard to imagine ever forgetting major designs and decisions, but the more time that passes the more details are forgotten and the more likely it is that original implementation team members have moved on.

Upgrading or changing custom features

When you want to upgrade a custom feature or even make some tweaks to it, if there isn’t any design and/or development documentation for that feature it takes a lot of time digging into the code to figure out exactly what the feature is doing before any changes can be made to it.

Changing business processes

When you want to change some of your business processes, there is a great risk that you will go down a path that the original implementation team had a good reason for avoiding. You could end up spending a lot of time trying to figure out why the original decisions were made and what issues you might run into by changing them.

Adding a new feature

When you want to add a new feature you could inadvertently break a previously developed feature. Without having the documentation for that feature, it’s hard to know exactly how it was developed originally and what changes could affect it.

Decision to document depends on many factors

Now you may be wondering – does this mean I have to spend hundreds (or even thousands) of hours documenting every little piece of the implementation? Unfortunately, there isn’t a very clear answer to this. It really depends on many factors including the size of your implementation, the budget and timeline for your implementation, and the number of people involved among many other things. You will have to determine for your implementation and your organization what the right level of documentation is.

What to consider when deciding on project documentation:

Is it something that affects a major part of your business?

Usually, there are some core business processes that, if they aren’t functioning right, can greatly impact your ability to do business. It is highly recommended that anything related to those core business processes be documented.

Are there multiple people working on this process/piece of functionality?

The more people that are working together, the higher the need for documentation to make sure everyone stays on the same page.

Is it a complex process or feature?

If it’s complex with a lot of moving parts, it’s important to document how all the pieces work together.

Is it a process within an area of your business that sees high turnover?

If you have high turnover in an area of your business and people are coming and going fairly frequently, it is important to make sure processes within that area are clearly defined and documented.

Are there planned changes or upgrades for this area?

If you are planning a future phase which will add more functionality or improve on the existing functionality, it’s important to have clear documentation around the processes and features that will be modified at a later date.

Project documentation recommendations

We recommend that you decide at the beginning of your project what level of documentation is necessary and then be sure to add time to complete that documentation into your budget and timeline. The important thing to remember is that the cost and time you save by not documenting something could end up being consumed many times over later down the road because you don’t have that documentation.

Related Posts

  • In the first part of the project management series, I discussed the planning phase and how important a good project charter is to a project.  I've developed this questionnaire over…

  • On Thursday at Convergence, I had the opportunity to present a session entitled 50 Tips in 90 Minutes for Better Project Management.  To my surprise we had a huge audience…

  • You have received your new proposal from your partner for a Microsoft Dynamics Implementation and are reviewing the services section looking for ways to trim cost. At last your eyes…


Submit a Comment

Your email address will not be published. Required fields are marked *

Upcoming Events


01sep10:00 am10:30 amEnsuring Quality and Compliance for Batch Manufacturers in Life Sciences

01sep12:00 pm12:30 pmIs it Worth It to Move to the Cloud? A Look at Considerations for Current Agribusinesses Using Dynamics GP

01sep2:00 pm2:45 pmWhat’s New in Dynamics 365 Finance and Supply Chain

09sep11:00 am12:00 pmConfab Live with Stoneridge – Data Strategy and Reporting – Mining Decision Making Insights

15sep10:00 am11:00 amSolving the Biggest Challenges in Agribusiness Through Innovation and Technology

22sep12:00 am12:30 pmSimplifying Payroll and HR Management with ADP Workforce Now

22sep10:00 am10:30 amStreamlining Batch Manufacturing with Technology

22sep2:00 pm2:30 pmProcess Automation for Microsoft Dynamics D365 for Business Central, Finance and Operations and GP

23sep11:00 am12:00 pmConfab LIVE with Stoneridge - Riding the Wave 2 Release – Key Features Coming to Dynamics 365 this October

29sep10:00 am11:00 amTop Five Reasons Why NOW is the Right Time to Move from Salesforce to Dynamics 365 Customer Engagement

29sep12:00 pm12:45 pmUnderstanding Job Costing and Tax Management in Business Central

29sep2:00 pm3:00 pmDigitalizing Horticulture & Agriculture - How to Sell Plants Online and Simplify Business Management

30sep12:00 pm4:00 pmSecurity and Permissions Training for D365 Business Central or Dynamics NAV


06oct10:00 am10:30 amPreview of D365 Business Central Fall Release Features and Functionality

06oct12:00 pm12:30 pmInsider's Guide to New Features Available in the Fall Release of D365 Finance and Supply Chain

07oct11:00 am12:00 pmConfab LIVE with Stoneridge - Dataverse and Dynamics in Review – Let’s Get Technical

13oct12:00 pm12:30 pmWave 2 Release – What’s Coming for Dynamics 365 Sales and Customer Service

21oct11:00 am12:00 pmConfab LIVE with Stoneridge - Dataverse and Dynamics in Review – Let’s Get Functional

26oct(oct 26)9:00 am28(oct 28)5:00 pmStoneridge Connect Leadership and Community Conference

About Stoneridge
Stoneridge Software is a unique Microsoft Gold Partner, with emphasis on partner. With specialties in Microsoft Dynamics 365, Microsoft Dynamics AX, Microsoft Dynamics NAV, Microsoft Dynamics GP and Microsoft Dynamics CRM, we focus on attracting the most knowledgeable experts in the field to our team, and prioritize delivering stellar solutions with maximum impact for your business. At Stoneridge, we are deeply committed to your results. Each engagement is met with a dedicated team, ready to provide thorough, tailored, and expert service. Based in Minnesota, we intentionally “step into your shoes,” wherever you are. We focus on what you care about, and develop trusting, long-term relationships with our clients.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!