See the Forest for the Weeds

Everyone has heard the trite saying, "See the forest for the trees".  We often get caught up in details and miss the bigger picture or the context of those details.  Another interpretation might be that it means focusing too much on tactics without focusing enough on strategy.  Well, sometimes I'd be happy if it were just forests and trees, as I've found on some of my projects, there are forests and trees, but also weeds.

If we are in the middle of a complex Dynamics GP implementation, we may be so focused on complex and highly detailed configuration or technical issues that we neglect or avoid other important higher-level project management tasks, such as communication, original requirements, priorities, deadlines, risks, and perhaps even customer satisfaction.

After doing consulting work for almost 15 years, I've observed something about myself and how my brain seems to work in different roles on projects.  I observed that I can write code, research technical issues, reverse engineer complex processes, and work on excruciatingly detailed tasks.  I also observed that I can manage projects, manage resources, manage budgets, manage teams, manage client communications, and coordinate dozens of tasks simultaneously.  I'm pretty comfortable that I can handle both of those roles.

But several times, to my surprise, interest, and frustration, I have found that I can't seem to do both of those simultaneously on the same project.  Maybe to some extent I can manage a project and handle a small subset of detailed tasks, or help jump into a complex issue to help resolve it.  But, for instance, I found that it is very difficult for me to handle 120 hours of development on a complex integration while simultaneously managing multiple tasks, resources, or deadlines that are completely separate from those development tasks.

I recently had a project management conference call for a project where I had been working evenings and weekends to develop an application, make dozens of modifications as requirements rapidly changed, and perform hours of testing on dozens of test case scenarios.  I have been deep in the weeds for several weeks.  When we started discussing other tasks on the project, I literally didn't remember some items that were discussed in previous conference calls.  I had been so focused on one application and its code that I seem to have forgotten or ignored the subsequent tasks, which were no less critical, but were things that I had not yet started working on.

My only interpretation at this point is that when I am swimming through 3,000 lines of code, my brain is extremely focused on hundreds of details, "loading" many of those details into memory as I scan and jump through the code.  Writing code, I have to be able to trace processes throughout an application, from querying a database, to transforming data, to validating field values, to inserting transactions, along with error handling and configuration files, all of which requires extraordinary attention to detail, since programming languages won't forgive an incorrect character, missing line, or improperly placed parenthesis.  I have to enter a "zone" to navigate the code, which takes time and concentration, but once I'm in that zone, I'm able to efficiently work at that level of detail.

But when I have to manage a project, it seems to be a very different mindset or set of mental skills.  It involves synthesizing more discrete elements, such as resources, tasks, dates, dependencies, or meetings.  It involves a lot more mental "task switching" that seems to require fundamentally different thought processes than coding.  Managing projects and delegating tasks, I'm typically able to stay out of many of the details, which I speculate allows me to perform that task switching without having to enter a "zone".

I've spoken with colleagues about this observation, and they generally seem to agree with the concept, and I've noticed this with consultants that I've managed.  While they are working on a detailed, task, if I ask them about other tasks and how they are going to prioritize them, I see the familiar blank stare.  They were so busy fighting with Integration Manager for the last hour that they haven't been able to step back and look at all of the pending tasks.


I also find that this affects how I transition from one task to another.  After I finish some code, complete the documentation, and make a backup of everything, I find it is sometimes difficult to move on to a completely different task, whether detailed or high level.


I think the lesson here is that if you have similar observations and experiences, try and keep this concept in mind when managing a project.  Your project managers will likely become frustrated with your consultants and developers as the consultants and developers are dealing with mental whiplash trying to transition between tasks.  And your developers and consultants may need to develop some practices to help them manage their assigned tasks and lower the cost of transitioning from one task to another.

As someone who often develops and goes deep into "the zone", I think I need to develop better practices to make sure to allocate some time on a daily, or at least weekly basis, where I focus on the trees and the forests before I dive into the weeds.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified Professional.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com