This summer, I had the incredible opportunity to work as a project management intern at TRS planning. During my time there, I was able to immerse myself in various tools, technologies, and strategies that enhanced my understanding of project management and honed my skills in real-world applications. Here’s a look at the key projects I worked on and the skills I developed.
Redesigning the TRS Planning Capability Statement
One of the first tasks I was assigned was to redesign the TRS Planning Capability Statement. This document is crucial as it serves as the face of the company to potential clients and partners, outlining our services, expertise, and accomplishments. I worked closely with the marketing and design teams to ensure that the updated statement was not only visually appealing but also accurately reflected the company’s strengths and values. The new design was more streamlined, with clear sections highlighting our core competencies, project successes, and unique value propositions. This redesign was well-received internally and has since been used in multiple client engagements.
Mastering Project Management Tools: Trello, Lucid, and Upwork
Throughout the internship, I was introduced to several project management tools that are widely used in the industry. Trello, a powerful task management tool, became an essential part of my daily workflow. I used Trello to organize tasks, track progress, and ensure that projects stayed on schedule. The visual nature of Trello boards made it easy to collaborate with team members and provided a clear overview of ongoing projects.
Lucid, particularly Lucidchart, was another tool I learned to use effectively. This tool was instrumental in creating diagrams, flowcharts, and process maps that were integral to our project planning and execution. Lucidchart’s intuitive interface allowed me to quickly create and share complex diagrams that were easy for team members to understand and provide feedback on.
Additionally, I gained experience with Upwork, a platform for hiring freelancers. I learned how to navigate the platform, post job listings, and vet potential contractors. This was particularly useful for outsourcing tasks that required specialized skills, ensuring that our projects were completed efficiently and to a high standard.
Customizing RSS Feeds for Contractor Notifications
One of the more technical aspects of my internship involved customizing RSS feeds to notify us when contractors were looking for work. This project required a deep dive into how RSS feeds work and how they can be tailored to deliver specific, real-time updates. By setting up these customized feeds, we were able to stay ahead of the competition by quickly identifying and engaging with contractors who matched our project needs. This proactive approach not only saved time but also ensured that we had access to top talent as soon as they became available.
Creating a Workflow Chart Integrated with AI
A highlight of my internship was creating a workflow chart integrated with AI. This project combined my newfound skills in process mapping with cutting-edge AI technologies. The goal was to streamline our internal processes by identifying bottlenecks and areas where AI could automate repetitive tasks. The result was a dynamic workflow chart that not only mapped out the current processes but also included AI-driven suggestions for optimization. This chart has since become a valuable tool for the team, helping to increase efficiency and reduce manual workload.
Conclusion
My internship at TRS planning was an invaluable experience that allowed me to develop a wide range of skills, from design and project management to technical customization and AI integration. The projects I worked on not only contributed to the company’s success but also provided me with practical experience that will be essential in my future career. I’m grateful for the opportunity to have worked with such a talented team and look forward to applying what I’ve learned in future endeavors.
At TRS Planning, we specialize in helping small businesses scale their processes, generate more revenue, increase transparency, and reduce manual tasks. We often help business owners design, deploy, and operate solutions that enable them to do more work without hiring more people.
One common issue we’ve observed across businesses of all sizes is the selection, deployment, and operation of software.
The Rush to Software Solutions
In many cases, business leaders know that they have a problem and assume that a software product will solve that problem.
Some common problem statements that we hear are:
“We need something to help us get organized.”
“Spreadsheets aren’t working for us anymore.”
“As a business owner, I need to be able to see what my team is working on so I can help move things forward when they get stuck.”
“I think we’re too busy doing things that don’t generate revenue…”
“Our reputation with customers is at risk when we are late.”
One reflexive response is for business owners to look for software to deal with one or more of the problem statements mentioned above.
But, the rush to a software solution to solve problems often results in additional cost, lost productivity, and frustration.
Many times, small business owners will consult with other business owners and ask them “What software do you use to stay organized?” They’ll read reviews – and hopefully blogs like this one – to find out what products are available. They might even schedule demonstrations with product sales teams to preview the capabilities of different tools.
We have observed, however, that many clients are operating processes that cannot be improved by simply installing project management or collaborative workflow software. So, when they jump to the decision to purchase a software solution, they later observe a mismatch between their expectations and the actual results.
The Features Comparison-Based Approach
Other companies take a slightly different approach to software selection by adopting a “features comparison” approach. This is also referred to as “requirements-based” approach. They generally begin with the same unvalidated assumption as the “Rush to Software” approach:
“We need a software solution to help address [insert problem(s) here].”
Instead of defining and measuring the OUTCOMES of their processes, these small business owners often compare software features among different products. Many of these product features include interactive, cloud-based status reporting dashboards, resource management, or API integrations with their core business systems (Slack, Quickbooks, Salesforce, Goolge drive or Sharepoint).
Often, they come to us and say:
“We recently bought [insert software product here] – we just need a little help getting it set up…”
While the features-based approach is an improvement over the rush to a software solution approach, underlying process issues are often not addressed.
Don’t get me wrong, software features and requirements SHOULD be considered when selecting any tool. But, tooling requirements and features are only part of delivering work efficiently…
The Mechanism-First Approach
At TRS Planning, we believe in a different approach. We advocate for designing “Amazon-like” mechanismsfirst. A mechanism is defined as a complete, end-to-end process that reinforces and improves itself as it operates.
Building a mechanism starts with clearly defining the business challenge – in one sentence. And, If you have 2 sentences, you probably have 2 challenges…
After we concisely define the business challenge in one sentence, we work backwards (from RIGHT to LEFT in the Figure 1 below) to understand the desired outputs. And, we make sure that the outputs can be produced by the combination of:
A tool (the tool could be excel, Google sheets, OR a project management or collaborative workflow solution – it might even be a “home brew” solution they build)
User adoption (that is, the people doing the delivery work)
Inspection (usually a “process owner,” that is, someone who will keep an eye on everything, from start to finish, intervene when necessary, and sound the alarm when things aren’t working)
Next, we take into account the inputs that will be transformed by the tool, users, and owner, to deliver the outcomes that meet the business challenge.
Finally, we spend time thinking about HOW we will iterate and improve the mechanism to better deliver the desired outcomes.
We didn’t invent mechanisms at TRS Planning, but we’re good at designing and deploying them.
Figure 1: Depiction of a Mechanism
Ugh…
All this sounds like a lot of work to simply “plug and play” industry standard software that everyone’s using, doesn’t it?
It’s actually not that much work. In fact, we can usually go through our standard list of 25 questions to provide the basis for our design in a 2-3 hours.
Client Case Study: Contractor Onboarding
At TRS Planning we deploy a systematic approach to designing mechanisms. What follows is a step-by-step case study of how we designed a contractor onboarding mechanism as a Proof of Concept (POC) for one of our clients.
STEP 1: Clearly state the Business Challenge The first step was to clearly define the business challenge that needed to be addressed. We summarized our client’s business challenge in this one sentence:
“We need an intuitive and frictionless contractor onboarding process that reduces our Time to Productivity (TTP) to 4 days.”
STEP 2: Define the Desired Outputs We identified what the desired outputs of the mechanism would be for our POC. Measuring TTP is relatively easy and standard. But, how would we know if our mechanism was “intuitive” and “frictionless?” We decided that the following measurable outputs would indicate our mechanism’s success at meeting the business challenge.
Contractors gain access to five (5) core business systems
Three (3) one-on-one intro calls with named company leaders are completed
Six (6) one hour initial company training modules are completed
Four (4) onboarding documents are signed and stored in the HRIS
Post-onboarding questionnaire is delivered and completed with a calculated score equal to or greater than 4.35; and no individual questionnaire response is lower than 3 (using a Likert scale of 1-5)
STEP 3: Select the Tool We needed to recommend a tool for our clients to use. Their existing tool was a Google document that functioned as a checklist. We didn’t believe we could enhance that Google document to deliver automated reports on the measurable outputs that they wanted. But, we also knew that our client was using another very common collaborative workflow tool for 2 existing processes: Trello.
We determined that Trello could track and report on the required outputs. We also knew that we could leverage Trello’s “out of the box” automation to reduce manual tasks. And, since it was already in use by our client, this permitted us to avoid additional software costs.
Last, we hypothesized that leveraging an existing tool would help with our next step in designing the mechanism: user adoption.
STEP 4: User Adoption: A tool will only be effective if it is adopted by the users. Training is one key element to ensure adoption. But, there are other “levers” that we can pull and push to increase adoption.
Since our client’s team for whom we were designing this contractor onboarding mechanism was familiar with Trello, we assumed that we wouldn’t need to train them on the Trello basics. To validate this assumption, we proposed a handful of metrics related to delayed tasks, unassigned tasks, and “stale” tasks.
In the midst of designing our client’s contractor onboarding mechanism, we identified another distinct business challenge that caused us to recommend the establishment of an Operational Framework to solve a Trello data problem: Inconsistent data entry and task assignment in Trello. We theorized that, If implemented, a Trello Operational Framework would support the client’s contractor onboarding mechanism. We spun this off into a supporting effort.
For the onboarding contractors, however, Trello training would need to be added to a newly created training module. This new training module would need to be added to the company’s LMS and it would form the sixth module in the initial onboarding training package.
Finally, we theorized that transparent and company-wide accessibility to reporting would increase adoption by engendering self-policing behaviors while also allowing the mechanism owner to easily inspect reports as it operated.
STEP 5: Assign an Inspector/Owner: Assigning someone to inspect the outputs and reports of the mechanism is a key component of the mechanisms we build. In any organization the diffusion of responsibility can often put efficiency and desired outcomes at risk.
In our client’s small firm, the HR function was traditionally owned by the firm’s owner. But, when we designed the contractor onboarding mechanism, we recommended the firm assign ownership to the operations manager. We made this recommendation based upon the anecdotal evidence we uncovered during interviews of recently onboarded contractors and key leaders in the company.
Our hypothesis was that the firm owner’s skill-set and interest was focused revenue-generating business functions such as sales and business development. And, since the operations manager was incentivized to get the contractors onboarded within 4 days, their assignment as the inspector/owner made sense.
STEP 6: Define the inputs The next step was to think about and define the onboarding mechanism’s inputs. We knew that the client leveraged a Google sheet as an Applicant Tracking System (ATS). That Google sheet contained most of the inputs we needed: contractor name, start date, contact information, etc.
By leveraging some free software that ran on that Google sheet, we were able to trigger a process that exported that contractor data to a task in Trello. And that Trello task, in turn, triggered the start of the onboarding mechanism.
STEP 7: Iterate and Improve: Finally, we needed to ensure that everyone who had a hand in the mechanism – the owner, the staff operating it, and the new contractors – were provided with an easy way to report on the inevitable defects that arise with any newly deployed process.
We designed a simple way for anyone to report process or tooling defects. The defects were to be reviewed, on a schedule, by the designated inspector, who could then determine if those defects were inhibiting the mechanism. If those defects were deemed a priority, the inspector would transition those defects into the organization’s existing Trello operational workflow.
We also designed automated reporting that enabled the mechanism’s owner to make frequent inspections. We designed these reports to be delivered at various times during the onboarding process. And, of course, at the end, too.
Conclusion
By taking a mechanism-first approach, businesses can ensure that they select and deploy software solutions that truly meet their needs. Instead of rushing to a solution or choosing software based on a checklist of features, consider asking us to help you design your mechanisms so that they meet your business challenges.
