🧮ERP: Planning (Part V: It’s all about Partnership II)

When starting an ERP implementation project an organization needs to fill the existing knowledge gaps in respect to whatever it takes to achieve the goals associated with the respective project. Therefore, it makes sense to work with a implementer that can help cover the gaps directly or indirectly. Moreover, it makes sense to establish a long-term relationship that would allow to harness ERP system’s capabilities after project’s end, increase the ROI and, why not, find other areas of cooperation. It’s in theory what a partner does, and a strategic technology partnership is about – providing any kind of technological expertise the customer doesn't have in-house. 

Unfortunately, from being a ‘service provider’ to becoming a ‘partner’ is a challenging road for many organizations, especially when this type of relationship is not understood and managed accordingly. Partnership’s management may resume in defining common goals, principles, values and processes, establishing a communication strategy and a common understanding of the challenges and the steps ahead, providing visibility into the cost estimates, billing, resources’ availability and utilization. Addressing these aspects would offer a framework on which the partnerships can nourish. Without considering these topics, the implementer remains just a 'service provider', no matter of the names used to characterize the relationship. 

Now, the use of the word ‘partner’ would make someone think that only one partner is considered, typically a big to middle-sized organization that would have this kind of resources. The main reason behind this reasoning is that the number of functional areas and volume of skillset required for filling the requirements of an implementation are high compared with other projects, the resources needing to be available on-demand without affecting the other constraints: costs, quality, time. This can be challenging, therefore can be met scenarios in which two or more external organizations are involved in the partnership, ideally organizations that complement each other. 

It is common in ERP implementations to appeal also to individual consultants for specific areas or the whole project. The principles and values of a partnership, as well the framework behind, can be applied to individual consultants as well. Independently of resources’ provenience more important is the partnership ‘mindset’ - being together in the same boat, working together on a shared and understood strategy, with clear goals and objectives.

Moreover, the people participating in the project must have a ‘partner's mindset’ as well. Without this, the project will likely get different impulses in the wrong direction(s), as a group’s interests will take priority over the ones of the organization. Ideally, this mindset should extend to the whole organization as topics like Data Quality and Process Improvement must be an organization’s effort, deeply imprinted in organization’s culture.

More like ever, it’s important for the business to see and treat the IT department as a ‘partner’ and not as a ‘service provider’ by providing the needed level of transparency in requirements, issues, practices and processes, by treating the IT department as equal party in the decision-making and addressing its current and future strategical requirements. Ideally, this partnership should happen long before the implementation starts, given that it takes time for mentalities and practices to change, for knowledge to be acquired and used appropriately. 

Building a partnership takes time, effort and strategic thinking, this on top of the actual implementation, increasing thus the overall complexity, at least at the beginning. Does it pay off? Like in a marriage, it’s useful to have somebody you can trust, who knows you, whom you can rely upon, and talk with to find solutions. However, only time will tell whether such expectations are met and kept till the end. 

Previous <||> Next

🧮ERP: Planning (Part II: It’s all about Scope - Nonfunctional Requirements & MVP))

Nonfunctional Requirements

In contrast to functional requirements (FRs), nonfunctional requirements (NFRs) have no direct impact on system’s behavior, affecting end-users’ experience with the system, resuming thus to topics like performance, usability, reliability, compatibility, security, monitoring, maintainability, testability, respectively other constraints and quality attributes. Even if these requirements are in general addressed by design, the changes made to the system have the potential of impacting users’ experience negatively.  

Moreover, the NFRs are usually difficult to quantify, and probably that’s why they are seldom made explicit in a formal document or are considered eventually only at high level. However, one can still find a basis for comparison against compliance requirements, general guidelines, standards, best practices or the legacy system(s) (e.g. the performance should not be worse than in the legacy system, the volume of effort for carrying the various activities should not increase). Even if they can’t be adequately described, it’s recommended to list the NFRs in general terms in a formal document (e.g. implementation contract). Failing to do so can open or widen the risk exposure one has, especially when the system lacks important support in the respective areas. In addition, these requirements need to be considered during testing and sign-off as well. 

Minimum Viable Product (MVP)

Besides gaps’ consideration in respect to FRs, it’s important to consider sometimes on whether the whole functionality is mandatory, especially when considering the various activities that need to be carried out (parametrization, Data Migration).

For example, one can target to implement a minimum viable product (MVP) - a version of the product which has just enough features to cover the mandatory or the most important FRs. The MVP is based on the idea that implementing about 80% of the needed functionality has in theory the potential of providing earlier a usable product with a minimum of effort (quick wins), assure that project’s goals and objectives were met, respectively assure a basis for further development. In case of cost overruns, the MVP assures that the business has a workable product and has the opportunity of deciding whether it’s worth of investing more into the project now or later. 

The MVP allows also to get early users’ feedback and integrate it into further enhancements and developments. Often the users understand the capabilities of a system, respectively implementation, only when they are able using the system. As this is a learning process, the learning period can take up to a few months until adequate feedback is available. Therefore, postponing implementation’s continuation with a few months can have in theory a positive impact, however it can come also with drawbacks (e.g. the resources are not available anymore). 

A sketch of the MVP usually results from requirements’ prioritization, however then requirements need to be regarded holistically, as there can be different levels of dependencies existing between them. In addition, different costs can incur if the requirements will be handled later, and other constrains may apply as well. Considering an MVP approach can be a sword with two edges. In the worst-case scenario, the business will get only the MVP, with its good and bad characteristics. The business will be forced then to fill the gaps by working outside the system, which can lead to further effort and, in extremis, with poor acceptance of the system. In general, users expect having their processes fully implemented in the system, expectation which is not always economically grounded.

After establishing an MVP one can consider the further requirements (including improvement suggestions) based on a cost-benefit basis and implement them accordingly as part of a continuous improvement initiative, even if more time will be maybe required for implementing the same.

Previous Post <<||>> Next Post

✨Performance Management: Learning (Just the Quotes)

"Much learning does not teach understanding." (Heraclitus, "Fragments", 6th c. BC)

"Learning is more important than practice because it leads to practice." (Talmud, [Megillah] cca. 5th century BC)

“For the things we have to learn before we can do, we learn by doing.” (Aristotle, “Nicomachean Ethics”, Book II, 349 BC)

"Learning is its own exceeding great reward." (William Hazlitt, "The Plain Speaker", 1826)

"Thoroughly to teach another is the best way to learn for yourself." (Tyron Edwards, “A Dictionary of Thoughts”, 1891) 

"Learning is for the future; that is, the object of instruction is to facilitate some form of behavior at a point after the instruction has been completed." (Robert F Mager, Developing Attitude Toward Learning, 1968)

"Modern organization makes demands on the individual to learn something he has never been able to do before: to use organization intelligently, purposefully, deliberately, responsibly [...] to manage organization [...] to make [...] his job in it serve his ends, his values, his desire to achieve." (Peter F Drucker, The Age of Discontinuity, 1968)

"Learning does not occur because behavior has been primed [stimulated]; it occurs because behavior, primed or not, is reinforced." (B F Skinner, "Beyond Freedom and Dignity", 1971)

"Learning is finding out what you already know. Doing is demonstrating that you know it. Teaching is reminding others that they know just as well as you. You are all learners, doers, teachers." (Richard Bach, "Illusions: The Adventures of a Reluctant Messiah", 1977)

"Organizations tend to grow through stages, face and surmount crises, and along the way learn lessons and draw morals that shape values and future actions. Usually these developments influence assumptions and the way people behave. Often key episodes are recounted in "war stories" that convey lessons about the firm's origins and transformations in dramatic form. Eventually, this lore provides a consistent background for action. New members are exposed to the common history and acquire insight into some of the subtle aspects of their company." (Richard T Pascale & Anthony G Athos, "The Art of Japanese Management", 1981)

"The term closed loop-learning process refers to the idea that one learns by determining what s desired and comparing what is actually taking place as measured at the process and feedback for comparison. The difference between what is desired and what is taking place provides an error indication which is used to develop a signal to the process being controlled." (Harold Chestnut, 1984)

"Culture [is] a pattern of basic assumptions invented, discovered, or developed by a given group as it learns to cope with its problems of external adaptation and internal integration that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems." (Edgar H Schein, "Organizational Culture and Leadership", 1985)

"The style of participative management is at its best when the supervisor can draw out the best in his people, allow decisions to be made at the point of influence and contribution, and create a spirit that everyone is in it together and that if something is unknown, they'll learn it together." (Joseph A Raelin, "Clash of Cultures: Managers and Professionals", 1986)

"Teaching is only demonstrating that it is possible. Learning is making it possible for yourself." (Paulo Coelho, "The Pilgrimage", 1987)

"The ability to learn faster than your competitors may be the only sustainable competitive advantage." (Arie P. de Geus, Harvard Business Review, 1988)

"When a team outgrows individual performance and learns team confidence, excellence becomes a reality." (Joe Paterno, American Heritage, 1988)

"[…] new insights fail to get put into practice because they conflict with deeply held internal images of how the world works [...] images that limit us to familiar ways of thinking and acting. That is why the discipline of managing mental models - surfacing, testing, and improving our internal pictures of how the world works - promises to be a major breakthrough for learning organizations." (Peter M Senge, "The Fifth Discipline: The Art and Practice of the Learning Organization", 1990)

"A typical software project can present more opportunities to learn from mistakes than some people get in a lifetime." (Steve McConnell, "Rapid Development", 1996)

"Learning is the process of obtaining new knowledge. It results in a better reaction to the same inputs at the next session of operation. It means improvement. It is a step toward adaptation. Learning is a major characteristic of intelligent systems." (Nikola K Kasabov, "Foundations of Neural Networks, Fuzzy Systems, and Knowledge Engineering", 1996)

"Whoever teaches learns in the act of teaching, and whoever learns teaches in the act of learning." (Paulo Freire, "Pedagogy of Freedom", 1996)

"Learning is a multi-faceted, integrated process where changes with any one element alters the larger network. Knowledge is subject to the nuances of complex, adaptive systems." (George Siemens, "Knowing Knowledge", 2006)

"Learning is the process of creating networks. Nodes are external entities which we can use to form a network. Or nodes may be people, organizations, libraries, web sites, books, journals, database, or any other source of information. The act of learning (things become a bit tricky here) is one of creating an external network of nodes - where we connect and form information and knowledge sources. The learning that happens in our heads is an internal network (neural). Learning networks can then be perceived as structures that we create in order to stay current and continually acquire, experience, create, and connect new knowledge (external). And learning networks can be perceived as structures that exist within our minds (internal) in connecting and creating patterns of understanding." (George Siemens, "Knowing Knowledge", 2006)

"Learning is a process of modifying or completely changing our mental models based on new experiences or evidence." (Edward D Hess, "Learn or Die: Using Science to Build a Leading-Edge Learning Organization", 2014)

"No methodology can guarantee success. But a good methodology can provide a feedback loop for continual improvement and learning." (Ash Maurya, "Scaling Lean: Mastering the Key Metrics for Startup Growth", 2016)

"There is a remarkable agreement upon the definition of learning as being reflected in a change of behavior as the result of experience." (E A Haggard)

"We can expect the revolution in communications to extend the power of our brains. Its ultimate effect will be the transformation and unification of all techniques for the exchange of ideas and information, of culture and learning. It will not only generate new knowledge, but will supply the means for its world-wide dissemination and absorption." (David Sarnoff)

🔦Process Management: Process Improvement (Definitions)

"A program of activities designed to improve the performance and maturity of the organization's processes, and the results of such a program." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"Continuous improvement of work processes to achieve project goals and stakeholder satisfaction efficiently and effectively." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"(1) A program of activities designed to improve the performance and maturity of an organization’s processes. (2) The results of such a program." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The organized activity of defining, infusing, and improving the processes used by individual projects and organizations to develop software." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

[internal process improvement (IPI):] "An appraisal mode of usage in which organizations appraise internal processes, generally to baseline their process capability, to establish or update a process improvement program, or to measure progress in implementing such a program." (Sally A Miller et al, "People CMM: A Framework for Human Capital Management" 2nd Ed., 2009)

"A business management strategy focusing on quality control testing and optimizing processes through reducing process variance." (Evan Stubbs, "Big Data, Big Innovation", 2014)

[business process improvement (BPI):] "Analyzing and redesigning business processes to streamline them and gain efficiencies, reduce cycle times, and improve auditability and worker productivity." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"A program of activities designed to improve the performance and maturity of the organization’s software processes and the results of such a program." (CMMI)

🔦Process Management: Plan-Do-Check-Act (Definitions)

"The team first plans ('plan')who needs to know what information, how often they need it, and their preferred information format. Next the team uses ('do') the communications plan. Very quickly and repeatedly, the team should seek feedback ('check') on the quality and completeness of the information being transmitted through the communications plan. Finally the team should act ('act') on the feedback by improving the communications plan." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A basic technique for improving processes, created by Walter Shewhart. Also known as the Shewhart cycle or the Deming cycle (for W. Edwards Deming, who introduced the technique in Japan)." (Danette McGilvray, "Executing Data Quality Projects", 2008)

"Continuous improvement cycle originally developed by Walter Shewhart in the 1930s." (Bill Holtsnider & Brian D Jaffe, "IT Manager's Handbook" 3rd Ed., 2012)

"All refer to the process of improving quality through a defined series of steps." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement", 2012)

"Also Plan, Do, Study, Act the Shewhart Cycle or Deming Cycle. All refer to the process of improving quality through a defined series of steps." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"An iterative process for continuous improvement." (Weiss, "Auditing IT Infrastructures for Compliance, 2nd Ed", 2015)

"Plan = design/revise process, Do = implement the plan, Check = measure the process, ACT = plan & implement changes" (ITIL)