I had the opportunity to facilitate training for a graduate class where there was an interesting discussion about defining technical projects. Now, the discussions were really inspiring, and we discussed several different characteristics such as novel use of emerging 4th Industrial Evolution related technologies playing a critical role in creating a unique product, service, or result. At the same time, there were also some definitions of technical projects that need to be debunked.
Now, one of the promising unbiased definitions of a technical project is that technology is used in achieving project goals that otherwise are not possible or would take time. It is imperative that we don't limit ourselves to the "technology" itself as the use of "information technology". In fact, technology is broadly defined as the application of scientific knowledge or a structured approach to realize an objective. For instance, brainstorming ideas can apply the concepts of design thinking, Delphi techniques, nominal group technique or many other forms such as the 6-3-5 technique (Rajagopalan, 2020). In these brainstorming approaches, a technical tool can be used but it is not always necessary.
A few things that I would like to consider incorrect for defining a technical project are the following:
- Only technical projects have risks
- Risk is any uncertain event that can positively or negatively impact a project. So, it does not distinguish whether the project is technical or not. If the wrong hypothesis was chosen as the null hypothesis in a scientific project, it is a concept risk that impacts the project's schedule.
- Technical projects always have shorter timeframe
- This idea comes from the application of adaptive approaches (e.g.: Agile or Scrum) in technical projects. The reason for shorter timeframe in adaptive approaches to facilitate faster feedback from the users who may not always know what they want or may have changes in the upcoming iterations. Progressive elaboration has been present in project management frameworks for quite some time and the amount of time given for feedback facilitation is up to the project.
- Using Jira makes the project technical
- While Jira is an example here, the use of any tool for requirements, test cases, risks, defects, and any other artifacts used in a project does not make a project technical. By that definition, any project documenting its goals and objectives in Microsoft Word or even notepad should call that project as a technical project.
- Non-Tech projects do not use technology
- As mentioned before, technology is the methodical approach of using a technique. A project may use a technical tool like soil analysis to evaluate if a small campsite can be strongly established for training local students in agriculture. A business information modeling (BIM) tool can be used to design the intricacies of a building even before construction begins. Whether we classify such projects are technical or not, we can't say non-technical projects do not use technology.
- Non-Tech projects do not need special talent
- This is a biased statement thinking that special talent applies to people with advanced computer technology, data science, etc. A plumber, electrician, auto-mechanic, creative artist, musician, linguist, journalist, or market research specialist are all equally qualified special talent. Let us not forget the numerous specialty vocational schools that prepare people for many skills and competencies we take for granted.
- Quality is not relevant in non-tech projects
- This is a biased statement thinking manual testing, automated testing, robotic process automation, and several other quality control and quality assurance related professions that has emerged. Quality is a function of risk (Rajagopalan, 2023) and wherever there is a project, there is risk. So, to say that quality is limited only to technical projects and furthermore not relevant in non-technical projects is losing the foundations of total quality management principles.
- Cost is not relevant to agile projects
- This is a false thinking primarily because people don't incorporate cost-based decisions in their usual iteration/sprint planning. There is a cost to every iteration (Rajagopalan, 2019). Most often, people are not working freely in most of the professional projects except in the volunteer settings where people volunteer their time. Even in such cases, the opportunity cost of working on a feature that is less customer focused than the feature the customer wants is always at the epicenter of MVP (Minimum Viable Product) discussions as part of risk-adjusted prioritization in product planning.
Thoughts? Love your comments.
References
Rajagopalan, S. (2020). Alternative Idea Generation: 6-3-5 technique. https://agilesriram.blogspot.com/2020/01/alternative-idea-generation-6-3-5.html
Rajagopalan, S. (2019). Agile iterations also involve cost. https://agilesriram.blogspot.com/2019/04/test-post.html
Rajagopalan, S. (2023). Quality is a function of risk. https://agilesriram.blogspot.com/2023/03/quality-is-function-of-risk.html
