Reflections on decision making in IT Projects

Marlene Sanchez  - IT Architect

October 2013

Since I began my career some years ago, I made decisions that hopefully resulted in positive results, while others were completely disastrous. If you asked me what percentage of those delivered the expected results versus non expected ones, I would say that maybe 50/50, and to be honest I was never comfortable with that statistic given that I wanted to have mostly positive results. However during those days, I was not able to identify if I have used the correct reasons and rational during the decision process.

Now, during my masters, I had the opportunity to read a book recommended by a brilliant professor that explains decision making and which make me understand my decision making process and the rationale behind it. This last has been a positive breakthrough for me not only at work but also in my personal life.

And based on this valuable experience, I want to the share with you some important concepts of the book and some applications of this theory in the IT field so you improve your decision making abilities.

The Decision Making Process

For this blog, I’m going to give an general resume of the book “Thinking, Fast and Slow” from Nobel Laureate Daniel Kahneman (specifically I read parts 1 and 4 for this book and the first appendix). In resume, in the mentioned chapters the author explains: 1) the decision making process of a human, 2) where decision biases come from, and 3) why people´s rationality use to fail.

Initially, Kahneman divide in two phases a person´s decision process. The first part is called “System 1”(Fast Thinking) and is responsible for: associations among ideas, detection of simple relationships, priority assignment of self-protecting actions, hostility detection, expression of feelings, among others innate skills . In short, System 1 is our intuition and it is normally impulsive, impatient, and operates automatically and very quickly. Conversely, Kahneman defines the second part as System 2 (Slow Thinking), the conscious and reasonable self that:  has beliefs, requires concentration and attention to perform a task, has a limited capacity and is responsible of comparing, choosing, and following rules. Just to exemplify, if you see an angry human face, System 1 is the one that identifies the feelings that the person is expressing; however if you are asked to perform the product 56x78, System 2 is involved since you require to maintain in memory several ideas simultaneously.  

According to Kahneman, System 2 monitors and controls thoughts and actions of System 1 to take reasonable decisions, however sometimes System 2 endorse System 1´s intuitive answers due to certain specific beliefs and personal background. In this regard, an experience that an individual lived and that is transformed into a personal belief can affect the reasonable decision process. For instance, a person can use representativeness[1] as heuristic to predict the nationality of people in a room, however if its decision is based on stereotypes about races, he will experience a narrow frame[2] issue, given that he will categorize a person using cognitive shortcuts influenced by his beliefs and not using useful statistical information that could converse to a more accurate prediction.

In addition, Kahneman affirms that “System 2” can experience a flaw of reasoning due to overload; and given that fact, it tries to achieve a goal selecting the least demanding course of action, which results in cognitive errors. This specific situation is called “Lazy thinking”.

Finally, although the author give great emphasis on cognitive issues generated on “System 1”, he also accepts that System 2´s rationality skills are limited and sometimes can generate biased conclusions.  In this regard, the author recommends that Organizations help humans improve decision making by the implementation of procedures and policies

Decision making problems in IT Projects

Working in an IT firm allows you to interact with a lot of managers, which contrary to my belief, base their decisions on personal judgments. No surprisingly I have witnessed the consequences of such practices that turn out to be: delays in project schedule, and loss of client credibility and profit. For instance, I worked in a project that was delayed by approximately one year; however management team extended the project duration even if the company began to experienced losses. Some managers claimed that this project was a door to new opportunities with the same client, however after reading Kahneman´s book, I began to question if senior managers were facing loss aversion[3] in this subject.

So, in my perception managers were influenced by stereotypes of “Project Hero”. And obviously, they could´t visualize themselves as “the manager who cancel the project” even if they were losing more and more money. The team had worked weekends, days and nights and the client evaluates its performance as mediocre. Is it possible that this client is going to recommend our work for another project?

In my humble opinion, management team should be rational and consider serious calculation of Expected Monetary Value and Risk of its decisions. If it´s true that there is a great risk of losing this client, we also have a great risk of not obtaining a second contract, so given these facts I recommend the following options: 1) educate managers to use efficient methods of decision making like: risk return frontier or other statistical and forecast methods and 2) create policies to avoid irrational  decisions of managers. Both options not only will help the company to achieve a better wealth, but also they are going to guide our managers to become better decision makers and increasing their general wealth also.

Finally, clever policies that force canceling problematic projects not only could avoid “biased decisions” but also can help managers to understand consequences of supporting partial judgments. Managers must be aware of our human limitation to make rational decisions.

Conclusion

It is evident that all human beings try to make reasonable decisions, however our nature did not help us to do so. And in this regard we must develop our consciousness about ourselves and identify the real reasons behind our decision making process. This is a continuous work that we must perform and that requires personal responsibility. Are you ready to do it?  

[1] The representativeness heuristic is used when making judgments about the probability of an event under uncertainty (Kahneman & Tversky, 1972)

[2] Tendency of people to evaluate a risky prospect in isolation rather than mixing it with the other risks they face. http://www.eief.it/files/2009/01/paper_december_22_08.pdf

[3] Loss aversion refers to people's tendency to strongly prefer avoiding losses to acquiring gains. http://en.wikipedia.org/wiki/Loss_aversion

References

Kahneman, Daniel (2011). Thinking, Fast and Slow. Penguin Books. Introduction, Part 1

(Section 1,2 and 3), Part 4, Conclusions and Appendix 1.

Reflections on How IT can change the Healthcare Industry in Mexico

Marlene Sánchez IT Architect

October, 2012

Key contributions regarding digital transformation could be analyzed in Mexican Healthcare industry, which has not been disrupted by Internet given the mandatory personal attention provided by physicians and the levels of poverty in the country. Mexican patients know that in order to have proper medical attention they have to 1) pick-up the phone and schedule a monthly/weekly or yearly appointment with the physician 2) Go the appointment and be examined 3) Buy the recommended prescription or make some extra medical studies and 4) Continue with the treatment. Now, picture the following scenario: 

One patient has 62 years old and began to experience symptoms of a neurological disease that must be treated by more than one specialist in less than 24 hours to avoid complications, however no medical institution or private physician is able to share the patient medical record electronically to reference the patient urgently, which of course delay the diagnosis. What is the result? The patient finished with several complications that will jeopardize her/his quality of life for the next years. So, after this analysis I begin to ask myself how IT could transform the end of this story and what implications this transformation could bring to the Healthcare Industry. Responding to those questions is the purpose of the following document.

Healthcare industry in Mexico is composed of the following roles in the supply chains: Physicians, Patients, Medical institutions (e.g private or public hospitals), pharmacies and laboratories. Some physicians have paid for customized software to manage patient records however the small ones still managing their information in paper. Now, some medical institutions have implemented successfully Electronic Medical Record (EMR)¹ systems, nevertheless physicians are not able to connect to those systems. So based on those facts, I affirm that a digital transformation in Mexican Health care industry requires standardization of information to ease interoperability among systems and to be able to open new ways of operation. In this regard I picture the development of an open standardized IT platform that will emerge as a disruptive change offering benefits to patients and physicians² and that after some time it will be considered an open standard due to network externalities to the entire supply chain. In this regard, IT can ease prescriptions generations, medical schedules and referrals, communications among physicians and the supply of drugs.

Lead physicians that adopt this platform will be able to offer extra services to their patients like: online appointment, e-prescription, and e-referral that can diminish the overall process time. When the network  begins to grow physicians will be able to reference patients to different doctors and they all will be beneficed by scale economies. In this regard, other physicians will be obligated to adopt the platform to remain competitive while medical institutions and pharmacies will be motivated to join the network. The mentioned IT platform will allow discovering of new business opportunities in the Health care Industry, for instance, doctors will be able to share prescription information to pharmacies which could improve the forecast of drug demand.

Furthermore, Health care industry could suffer a change in its structure using an IT platform since laboratories could reach patients directly to market new drugs based on their record history and doctors could analyze patient information and offer discounts in order to promote preventive and regular checks. Furthermore, pharmacies role could change since those firms won´t need to review and validate the eprescription, allowing these entities to focus more on CRM initiatives. On the other hand, an IT platform can impact considerably the medical business structure, given that centralization of information (EMR) can ease decentralizing of diagnosis process. For instance, physicians located in different geographic locations could be working on the same case in order to deliver a more accurate diagnosis to the patient. It is important to mention, that the introduction of a new platform could generate rejection among the supply chain parties and within the industry given that the new technology doesn´t necessarily offer all functionality that some of them use to manage. However, users and the marketplace must be convinced to accept the change with the equally dramatic new benefits³.
 

Now so far, I have exposed the value of IT through the innovations of processes and business models in the Health care Industry in order to improve customer service; however it will be wise to talk about the competitive advantage of this transformation and what factors should decision makers take into account in their business strategies. And in this regard, I must say that decision makers in this industry must be aware that new sustainable and disruptive technologies can show up and new medical standards could emerge, and that even with all those changes they have to promote sustained initiatives to continue innovating business practices⁴ in order to remain competitive. Moreover, I advise physicians to spend in IT platforms that differentiate them from other practitioners and that allow them to offer better service to their patients; all roles in the supply chain should treat IT as an opportunity to define and deploy new ways of working⁵.

In conclusion, if a platform like this could exist, many users could be more pleased with the medical service and more business opportunities could be discovered within the Health care industry.

References

[1] Ximena Cassab,“La digitalización de expedientes revitalizaría el sector salud en México”, CNN Mexico, January 2012, downloadedfrom  http://mexico.cnn.com/salud/2012/01/24/la-digitalizacion-deexpedientes-revitalizaria-el-sector-salud-en-mexico

[2] Clayton Christensen, “How can we beat our most powerful competitors”, HBS Press Chapter, 2003.

[3] Geoffrey  Moore, “Crossing the Chasm and Beyond”, HarperBusiness, 2002.

[4] John Seely Brown, John Hagel III, “Does IT Matter? An HBR Debate”, Harvard Business Review, May 2003.

[5] Andrew Mcafee and Erik Brynjolfsson,”Dog Eat Dog”,The Wall Street Journal, April 2007.

How the Personal Software Process (PSP) can bring consciousness and discipline to Computer Science and IT Professionals

Marlene Sánchez – IT Architect

September 2^nd, 2013

A couple of months ago, I posted an article regarding the importance of the Documenting Discipline on IT projects in which I provided some recommendations to support the practice. Specifically, I proposed the utilization the PSP (Personal Software Process) to educate IT professionals on that discipline; however this recommendation initiated an interesting and polemic discussion among my colleagues about how this can be possible.

So given the previous fact,  in the following post I will provide a supported argument regarding how PSP (Personal Software Process) can change the mindset of Computer Science and IT professionals to make them more disciplined, committed and responsible on the work they are performing. I want to support my recommendation not only to promote the discipline of documentation but also to improve IT professional´s daily work.

Personal Software Process (PSP): Definition and background

The creator of this process, Watts Humphrey defined PSP¹ as a self-improvement process that help software engineers to control, manage and improve the way they work. Humprey created this process to address common problems that companies face when they are creating software products, for instance: creation of poor quality software, delay on delivery time, over budget, and excessive repair of software products.

During his research, Humprey discovered that software engineers apply intuitive software processes when they are constructing software artifacts which works fine for simple and non-complex systems. However, when a software product is complex, the productivity of an engineer or team is jeopardized, since intuitive processes (given their non-repetitive nature) add more complexity and errors to the development effort. For instance, If I as a developer have applied intuitively a software process that includes steps A,B and G and a colleague next to me that is working on the same project and module uses his own process that includes step A, C, D and E,  to produce a similar product, there is no way in which we can compare our productivity or expect to deliver a product with the same quality and on similar timing. In this regard, it could be that I have considered using a list of common errors with their correspondent solution which could diminish code time in contrast with my colleague, who uses to reanalyze an error every time it is presented. So, the truth is that, without standardization, consciousness and metric comparison among colleagues and yourself, It´s not possible to know which process makes the professional more productive and in this specific point is where PSP enters the picture.

Personal Software Process (PSP) in Action

In practice, PSP is implemented by phases and on each phase the IT professional creates consciousness of what he/she is doing right or wrong on the performed activities and how he/she can improve. How this happens? Well, It´s similar to learn to play violin since you need to actually see yourself on a mirror every day in order to observe your body movement and technique to identify what you can correct. The same occurs with PSP, however the mirror in PSP are the output metrics that the process generates for the professional. 

In resume, PSP has three levels of maturity: 1) PSP0 and PSP0.1 that introduce initial process disciplines and measurements 2) PSP1 and PSP1.1 that introduce detailed information of estimation and planning and 3) PSP2 and PSP2.1 that introduce quality management and design. In practice, new metrics are included by level and each superior level implies more maturity and better process ‘outcomes (e.g. products without bugs and on time)

So after this basic explanation of PSP, let me exemplify its application with a real example:

Suppose you are a programmer that wanted to construct a module for credit card validation using PSP0. In this scenario, your inputs to the process should be: 1) functional description of what is needed, 2) required measure forms: Plan Summary, Time Recording Log and Defect Recording Log, 3) Defect Type Standards and 4) a watch (digital or analog) for time recording.

Now, PSP0 establishes three macro phases that are mandatory in the process: Planning, Development, and Postmortem. In the Planning phase professionals must estimate the time to perform their activities and must document estimated numbers on the Plan Summary Form. On the Development phase professionals must use their preferred software methodology (e.g Waterfall, RUP, agile, etc) to implement the program and must document the real time spent on each of the performed activities (e.g. design/implementation/compile/test) on the Time Recording Log (including interruption time), as well as defects encountered on the Defect Record Log. Finally on the Postmortem phase professionals must complete the project plan Summary with the actual time and defects encountered during the development process and analyze the final metrics. Why is this valuable for a developer? Well, after completing the process it is proved that programmers are able to identify:

•          Problems in their estimation efforts that derive on delay on activities
•      In which part of the process they inject more errors
•      Which problems take more time to solve and why
•     Flaws in part of the process that derive on error injection. For instance, lack of documentation activities in the process

So thank to PSP, professionals can visualize and manage specific opportunity areas in future iterations and be able to compare metrics against other colleagues and themselves. The discovering of root causes of problems is eased and new strategies can be applied iteratively. In this regard, continuous improvement becomes a personal challenge for them and they are committed to that idea. 

PSP for all Professionals

Finally, after visualize PSP0 in Action, you must be thinking that PSP can be used only on software development activities, however this not true since all kinds of processes can be measured and improved based on previous iterations metrics. For instance, if you are an IT support professional, you can analyze your support process and assess your performance to become more productive, so it is important to be open and embrace a continuous improvement methodology, no matter which kind of IT specialist you are.   

Conclusion

In conclusion, the Personal Software Process (PSP) is the first step for Computer Science and IT professionals to become more disciplined, committed and conscious about their daily work. It is a fact as well that the process can bring improvements to your personal performance and to the company you work for. Indeed, the process will help you to identify if your current processes are the best ones, or if documentation generated in your projects is a root cause of failure. So, be ready to embrace a continuous improvement methodology, you will not be sorry.

References

                                                                          

[1] Humphrey Watts, “PSP A Self-Improvement Process for Software Engineers”, SEI Series in Software Engineering, Addison Wesley, 2005

Reflections on technical people that obtain managerial positions

Reflections on technical people that obtain managerial positions
Marlene Sánchez – IT Architect

11 August 2013

This week I´m going to discuss the following question, which I think is an important reflection in the IT field: Can technical people become capable managers?   I put this question on the table, since almost all my colleagues and I have experienced frustration when working with technical managers, and it is worth to speak loudly about it, not only to understand what the problem is but also to consider what is needed to became a better manager. 

¿What is the manager´s job?

So, to explain what is the manager´s job, first I´m going to mention the roles that a manager must perform, which are explained clearly by Henry Mintzberg in its HBR classic, “The Manager´s Job: Folklore and Facts”¹. In this article, Mintzberg mentions that a manager must perform the following 3 important roles: Interpersonal, Informational, and Decisional during his/her administration. In resume in the interpersonal role, the manager must be the head of the team, the leader and be the liason with other teams. In the informational role, the manager must be able to monitor work, disseminate information and be the Spokesperson of the team. And finally in the Decisional role, the manager must act as entrepreneur, disturbance handler resource allocator and negotiator. It is important to mention that additionally to those roles; the manager must be the formal authority of the team and must provide status to different stakeholders. So, can you see why being an efficient manager is not easy?

The facts of technical people and technical managerial positions

Technical people are amazing since they are creative and analytical problem solvers², however they use to be introverts and less emotional which could be a constraint to become an efficient technical manager.  For instance, in software projects, technical manager use to have gaps in one of the mentioned managerial roles due to a constrained technical vision and lack of communication skills which can jeopardize a project and have serious monetary losses and human resource problems. Although, it is true that some technical staff can be more social that others, a managerial role requires well specific managerial skills that certainly are not easy to obtain in the short term.

On the other hand I also have identified a perception problem that technical people use to have. For example, 8 of 10 technical managers which I have worked with believe that being promoted to a manager position is the final objective of its career and that after getting there, there is no need to study because all managerial skills magically will be developed, which in my perception is completely false assumption, considering the fact that managerial positions implies the beginning of a new career, where the professional must develop new skills not only in theory but in practice and where continuous improvement is mandatory since management theory change from time to time. 

And finally, it is important to mention the fact that technical managerial positions use to be assigned to technical staff that shows commitment with an enterprise but that has not developed managerial skills in advance, which of course represents a risk for the company.  Let´s remember that the most important resource of IT is human and putting a person in a managerial position without those skills can be indeed problematic.

¿Can technical people become capable managers?

In my opinion they can, but obviously they have to acquire the required skills in a period of time. Indeed, they must focus in developing the Interpersonal and Informational roles since they use to have a gap in communication and leadership skills. In this regard, I recommend that technical people take leadership and communication training which will give them the theory, but also they should be mentored by an experienced manager that gives advice in certain practical situations. This experienced person should be side by side with the new manager in order to share thoughts and knowledge that sometimes is completely pragmatic.

Conclusion

In conclusion, if it is true that technical people can become efficient managers, it is also true companies must train their staff before giving them a manager´s responsibility. Just think about the time and money that a company could safe if they put skilled people in managerial positions.

References

[1] Mintzberg Henry, “The Manager´s Job: Folklore and Fact”, Harvard Business Review, March-April, 1990

[2]Mochal, Tom, “7 techniques for managing your technical staff”, October 2007, http://www.techrepublic.com/blog/tech-decision-maker/7-techniques-for-managing-your-technical-staff/

The Importance of Documenting Discipline in IT Projects

The Importance of Documenting Discipline in IT Projects

Marlene Sánchez – IT Architect

July 2013

Have you ask yourself what is the real importance of documenting a design, process or architecture? Do you imagine installing the electrical system in your house without proper documentation? Do you think chances of failure increase due to lack of documentation? Honestly, I hope that in some point of your career you have asked yourself these questions since from my perspective; a“Documenting Discipline” is a practice as important as constructing a final work product or delivering an IT service.

In a nutshell, the present publication aims to explain: 1) Facts and Reflections of the “Documenting Discipline” in IT projects 2) The consequences of lack of practicing this discipline 3) The importance and benefits of documenting; and finally provide recommendations to project managers and team leaders to promote this discipline.

Facts and Reflections of the Documenting Discipline in IT Projects

In my 13th year IT professional and 5th year as System, Architect, I have witnessed a generalized problem with the discipline of documentation in all Mexican teams with whom I have the opportunity to work. Indeed based my observations I have proved the fact that 9 of 10 professionals prefer to reanalyze similar problems they face, instead of documenting the resolution process one time and then reuse it in future situations. No matter if the professional is a software programmer, an analyst, consultant or architect; professionals by themselves don´t want to spend time documenting.

So after these observations, I began to question myself, why IT professionals act in that way. And after some years of observations and sharing ideas with my colleagues, I came to the following reflections about IT professionals:  1) Professionals don´t perceive that documenting is useful in their work since they believe they can handle all information in their heads 2) Professionals use to be in a hurry due to bad planning and certainly they prefer to finish their work instead of document it 3) Professionals find documentation boring and don´t know how to produce usable documentation 4) Professionals minimize the impact of not documenting due to lack of knowledge of the implications of not doing it and 5) Team Leaders/Managers don´t promote the usage of an established methodology and don´t specify which work products must be documented, so professionals don´t have a clear vision of what to document.

Now regarding the previous behavior, you may think that it is a problem of education, lack of training or bad planning, isn´t it? However, I believe that this could be a combination of the three plus additional factors that are enterprise specific like: management practice and internal policies since in some cases: 1) projects use to be sold without a plan that specifies time for documentation and 2) Team leaders/managers don´t promote documentation practices as standards in all projects.  The following cases not only will expose the rationale behind these behavior problems but they also will reveal the consequences of not having a documentation practice in place.

Consequences due to Lack of Documentation Discipline

To illustrate the consequences of lack of documentation discipline, I´m going to use two examples: 1) The case of a Mexican firm part of the Retail Industry and 2) The case of a transnational consulting firm. As you will notice, the first one hadn´t a documentation discipline implemented while the second had one in place but it was not followed by Project Managers.

Case 1: Retail Industry Firm

In the case of the Retail Firm, its IT department was focused on custom development and operated without formal documentation procedures. Architecture, designs and code blueprints were not available to developers so the following problems were recurrently present:

1.        Wasted Development Time and Code Duplication were constantly present since developers didn´t know which components exist in the application and they use to construct new work products from scratch
2.        Architecture decisions were not easily taken since there were no documentation of the AS-IS architecture
3.     .    Artifacts´ (i.e. processes, software components) Improvements  were not possible since developers and architects didn´t have an idea of how artifacts were constructed and with which rationale

In this regard, the department´s head was worried to solve urgent day to day development problems instead of identifying the real cause of deadline delays, which in part was the lack of maturity in its development and documentation processes. In this scenario, developers were not trained to appreciate the value of documenting their work and code was a black box that should be analyzed when it needed to be modified.

Case 2: Consulting Firm

Problems due to Lack of Documentation Discipline are also present in firms that offer technology consulting services, even if they own specific methodologies to deliver those services. Indeed, the consulting firm of this example was trying to deliver a system integration project to another big corporation in Mexico City, however the management team was not following the firm´s formal methodology to accelerate the implementation and as a consequence, no documentation discipline  was promoted which caused the following problems:

1. Operational environments (e.g. DEV/QA/PROD) were not installed with the same installation characteristics given that formal documentation of previous installation procedures were not created on time or shared to infrastructure team which caused inconsistencies in the implementation and design phases
2. Configurable Master data and business rules in “Out of the Box” applications were not replicated to all environments due to lack of documentation discipline which caused delay and rework on testing phase
3. No Knowledge Management strategy was defined and transferred to teams’ members that were part of the project, so documentation was out of date, incomplete and not exposed to other team members

Now, since the project was weak in documentation discipline and staff rotation was high, knowledge was lost when a new administration take control of the project which also caused delay project plans and monetary losses.

Importance and Benefits of Documenting

So, after considering the impacts of not having a Documenting Discipline, it becomes evident that the practice of documenting could bring the following advantages to IT professionals and IT Projects:

1.        Ease of decision making regarding architecture, designs, processes, or other artifacts that could be involved on the development/delivery process
2.         Delays of project schedule could be avoided if documentation is available and is useful to all team members
3.        Improvement of artifacts is easier given that team members could have a broader view of the system/process/design
4.        Time save is possible in application development since components could be reused or modified when needed and not duplicated
5.        And finally, On boarding process of new staff is accelerated when documentation is present

Recommendations to promote the “Documenting Discipline”

And now knowing the benefits that a Documenting Discipline can bring to IT projects and professionals, I share the following recommendations that will help firms/teams to promote the discipline of documentation.

1.        Methodology of deliver/development must define specific work products and must recommend which ones are mandatory depending on the case
2.        Firms must look for a good level of maturity in their IT processes (i.e. CMMI level 3, 4 or 5) and managers must follow these processes in all IT projects respecting the deliverables that are mandatory in order to promote documentation discipline
3.        Teams must define documentation templates  that must be standardized, used and understood by all team members in order to create mutual understanding
4.        Documentation Staff must be present in all IT projects in order to: 1) make sure that all mandatory artifacts are documented 2)  prepare documentation with team members 3) Explain the Knowledge Management process to all team members
5.        Peter Harrison¹, an author of Linux books recommends the creation of documentation projects to formalize the discipline which I have had the opportunity to implement in several projects and which works perfectly fine if a Knowledge Management initiative is in place
6.         And finally, documentation practice must be encouraged by managers, team leaders and enterprises and performed by professionals in a discipline way in order to obtain beneficial results. For instance, in custom development project it is recommended to implement a methodology like PSP (Personal Software Processes) in order to educate their staff on the benefits that documentation can bring to their work.

Conclusion

In conclusion, it is clear that IT companies and IT Leaders can obtain tangible benefits of a Documenting Discipline. However, implementing a Documentation initiative requires a change of mindset of people all over the company which represent a challenge, but not doing it will always represent a risk on any new project that want to be started. Think about it, can this initiative diminish your project´s technical debt?

References

[1] Peter Harrison, Linux admin fixes: Lack of documentation, http://searchcio-midmarket.techtarget.com/tip/Linux-admin-fixes-Lack-of-documentation