25 December 2012

Project Management: Project Management (Just the Quotes)

"Project management is becoming more important as equipment, systems, and projects become more complex." (Bud Porter-Roth, "Proposal Development", 1955)

"The classical vertical arrangement for project management is characterized by an inherent self-sufficiency of operation. It has within its structure all the necessary specialized skills to provide complete engineering capabilities and it also has the ability to carry on its own laboratory investigations, preparation of drawings, and model or prototype manufacture. (Penton Publishing Company, Automation Vol 2, 1955)

"The accuracy of estimates is a function of the stage of development (i.e. estimates improve as development of the item progress). This also means that estimates for development projects representing only 'modest advances' tend to be better than for more ambitious projects." (A W Marshall & W H Meckling, "Predictability of the Cost, Time and Success of Development", [Report P-1821] 1959)

"The difficulty in project management is how to apply competition between task efforts and between subtask efforts when such things as the task managers' work, schedules, and budgets are all different." (John S Baumgartner, "Project Management", 1963)

"If a given task depends on the completion of other assignments in other functional areas, and if it will, in turn, affect the cost or timing of subsequent tasks, project management is probably called for." (American Management Association, "Management Review", 1966)

"Basic to successful project management is recognizing when the project is needed - in other words, when to form a project, as opposed to when to use the regular functional organization to do the job." (David I Cleland & William R King, Systems Analysis and Project Management, 1968)

"Project management is not universally applicable. The utility of the idea depends on the magnitude of the effort, the complexity, the degree of unfamiliarity and interrelatedness, and the concern with the organization's reputation." (David I Cleland & William R King, "Systems Analysis and Project Management", 1968)

"Project management is needed only for situations which are out of the ordinary; but when the need exists, this may often be the only way by which the task may be handled successfully. These situations require a different attitude on the part of the top management, the undivided attention of a project manager and different methods for control and communications than those used in the normal routine business situation. […] Pure project management assigns complete responsibility for the task and resources needed for its accomplishment to one project manager. The organization of a large project, though it will be dissolved upon completion of the task, operates for its duration much like a regular division and is relatively independent of any other division or staff group." (Executive Sciences Institute, Operations Research/Management Science Vol 6, 1964)

"Project management is clearly a part of software engineering, and its effective employment plays a major role in reducing the problems associated with delivering software within estimated time and cost." (Richard H Thayer & John H. Lehman, Software Engineering Project Management, 1977)

"If a high degree of certainty exists concerning all major events, operations, and outcomes, project management is not essential." (John R. Adams et al, "Managing by Project Management", 1979)

"The acceptance of project management has not been easy, however. Many executives are not willing to accept change and are inflexible when it comes to adapting to a different environment." (Harold Kerzner, "Project Management", 1979)

"Generally, project management is distinguished from the general management of corporations by the mission- oriented nature of a project. A project organization will generally be terminated when the mission is accomplished." (Chris Hendrickson & Tung Au, "Project Management for Construction", 1989)

"An important part of project management is keeping track of thoughts, assumptions, suggestions, limitations, and the myriad related details of the project." (InfoWorld Vol. 12 (17), 1990)

"Project management is the art of creating the illusion that any outcome is the result of a series of predetermined, deliberate acts when, in fact, it was dumb luck." (Harold Kerzner, "Project Management: A Systems Approach to Planning, Scheduling, and Controlling", 2009)

"Effective project and program management involves more than strict adherence to a prescriptive methodology. Leadership skills, judgement, common sense, initiative, effective communication, negotiation skills and a broad perspective on the surrounding environment are all essential. Project and program management is a creative and collaborative process." (Peter Shergold, "Learning from Failure", 2015)

Project Management: Project Failure (Just the Quotes)

"Rushing into action, you fail.
Trying to grasp things, you lose them.
Forcing a project to completion,
you ruin what was almost ripe."
(Lao Tzu, "Tao Te Ching", cca. 6th-century BC)

"In many ways, project management is similar to functional or traditional management. The project manager, however, may have to accomplish his ends through the efforts of individuals who are paid and promoted by someone else in the chain of command. The pacing factor in acquiring a new plant, in building a bridge, or in developing a new product is often not technology, but management. The technology to accomplish an ad hoc project may be in hand but cannot be put to proper use because the approach to the management is inadequate and unrealistic. Too often this failure can be attributed to an attempt to fit the project to an existing management organization, rather than molding the management to fit the needs of the project. The project manager, therefore, is somewhat of a maverick in the business world. No set pattern exists by which he can operate. His philosophy of management may depart radically from traditional theory." (David I Cleland & William R King, "Systems Analysis and Project Management", 1968)

"A project is only as sound as its weakest assumption, or its largest uncertainty." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Faced with a decision, always ask one implacable question: If this project fails, if the worst comes to the worst, what will be the result? If the answer is total corporate disaster, drop the project. If the worst possible outcome is tolerable, say, break-even, the executive has the foundation of all sound decision making - a fail-safe position." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve C McConnell, "Software Project Survival Guide", 1997)

"Today, excellent companies realize that project failures have more to do with behavioral shortcomings - poor employee morale, negative human relations, low productivity, and lack of commitment." (Harold Kerzner, "In search of excellence in project management", 1998)

"Project failures are not always the result of poor methodology; the problem may be poor implementation. Unrealistic objectives or poorly defined executive expectations are two common causes of poor implementation. Good methodologies do not guarantee success, but they do imply that the project will be managed correctly." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"Success or failure of a project depends upon the ability of key personnel to have sufficient data for decision-making. Project management is often considered to be both an art and a science. It is an art because of the strong need for interpersonal skills, and the project planning and control forms attempt to convert part of the 'art' into a science." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"Today, most project management practitioners focus on planning failure. If this aspect of the project can be compressed, or even eliminated, then the magnitude of the actual failure, should it occur, would be diminished. A good project management methodology helps to reduce planning failure. Today, we believe that planning failure, when it occurs, is due in large part to the project manager’s inability to perform effective risk management." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"When unmeetable expectations are formed, failure is virtually assured, since we have defined failure as unmet expectations. This is called a planning failure and is the difference between what was planned to be accomplished and what was, in fact, achievable. The second component of failure is poor performance or actual failure. This is the difference between what was achievable and what was actually accomplished. […] Perceived failure is the net sum of actual failure and planning failure. […] Planning failure is again assured even if no actual failure occurs. In both of these situations (overplanning and underplanning), the actual failure is the same, but the perceived failure can vary considerably." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"You need to identify and terminate infeasible projects early. Sending a message to project managers that project termination threatens their career will tempt them to continue projects that should die” (Barry Bohem,"Project termination doesn't equal project failure", Computer, 34 (9),  2001)

"Projects fail because of context, not because of content.[...] the traditional emphasis in project management on the technical issues of the project (content) has led to a legacy of an extremely poor set of tools, techniques, and tips for managing the complex of people, political, and other 'softer' issues that make up the context of the project." (Rob Thomsett, "Radical Project Management", 2002)

"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses." (Barry Boehm & Richard Turner, "Observations on balancing discipline and agility", Agile Development Conference, 2003)

"As hard as it is to find good ideas, it's even more difficult to manage them. While the project is humming along, vision document in place and a strong creative momentum moving forward, there is another level of thinking that has to occur: how will the designs and ideas translate into decisions? Even if good designs and ideas are being investigated, and people are excited about what they're working on, the challenge of convergence toward specifications remains. If a shift of momentum toward definitive design decisions doesn't happen at the right time and isn't managed in the right way, disaster waits. For many reasons, project failure begins here." (Scott Berkun, "The Art of Project Management", 2005)

"Projects are complex non-linear systems and have significant inertia. If you wait to see acute problems before taking action, you will be too late and may make things worse." (Scott Berkun, "Making Things Happen: Mastering Project Management", 2005)

"Any effort at large-scale reorganization - that is, any project spanning more than two years and, more generally, anything that has not already been done - is inevitably doomed to failure." (Corinne Maier, "Bonjour Laziness: Why Hard Work Doesn't Pay", 2007)

"Stakeholder management to me is key, as success or failure is in the eye of the beholder. Time, cost and quality fall prey to the perceptions of the key stakeholders, who may have nothing to do with the running of the project." (Peter Parkes, "NLP for Project Managers", 2011)

"Reading reviews of failure can be a dispiriting exercise. It can also create a distorted perception of reality. Reform of the implementation of large programs and projects should not just be based on a litany of what has gone wrong. Many things go right and, for that very reason, go unnoticed." (Peter Shergold, "Learning from Failure", 2015)

"Complexity is one of the causes of failing projects; failing to split the project into smaller tasks also causes software quality issues or project failure. Complexity can also be caused by the size of the  project; if the project is too big, there is a huge possibility that the project may become complex and complicated." (Abu S Mahfuz,"Software Quality Assurance", 2016)

"A correct and sanity-checked judgment of both the financial and logistic feasibility of a project is absolutely critical to its eventual outcome; get it wrong and a failed project is almost guaranteed. In support of this statement we can refer to the contents of a number of serious ­academic studies which support the idea that two of the chief causes of the failure, particularly the financial failure, of major infrastructure ­projects are optimism bias and strategic misrepresentations. […] Optimism bias means that the original project sponsors and planners fooled themselves that the project would be easy and could be completed within a 'back-of-the-envelope' budget, perhaps because they didn’t have the experience to know it would be difficult and expensive, or perhaps they didn’t want to know. Strategic misrepresentations mean that even if they did know it would be more difficult and expensive than their published estimate, they lied about it so that the Public, the Banks, and Politicians, would support the idea." (Tony Martyr, "Why Projects Fail", 2018)

"No project should be allowed to proceed without clear specification and acceptance  criteria, that are understood by all participants." (Tony Martyr, "Why Projects Fail", 2018)

"[...] consistently good project results are hard to come by, yet most organisations continue to think they’re doing a great job. It’s got to the stage where project failure has become so commonplace that we’ve started to see it as success, or we just aren’t seeing clearly at all." (Tony Martyr, "Why Projects Fail", 2018)

"Every year more than two-thirds of projects are considered failures, and most organisations would not be surprised by this statistic. In most cases, however, failure was the result of not making a hard decision."  (Colin D Ellis, "The Project Book", 2019)

"Organisations whose IT projects failed usually deployed recognisable project management methodologies; the reasons for failure were invariably to do with failures of project governance rather than simply of operational management." (Alan Calder, "ISO/IEC 38500: A pocket guide" 2nd Ed, 2019)

"Part of the problem is that we take project failure personally, seeing it as a stain on our reputation. It’s worth remembering that while a project may fail, this doesn’t make you a failure as a leader. In fact, the research shows that those who embrace failure become much more resilient and make better decisions as a result, so in that sense failure can only be a good thing." (Colin D Ellis, "The Project Book", 2019)

"Remember, though, there are only two reasons for project failure: poor project sponsorship and poor project management. And given that the buck stops with you, you could argue there’s only one reason for project failure." (Colin D Ellis, "The Project Book", 2019)

"A project is usually considered a failure if it is late, is over budget, or does not meet the customer’s expectations. Without the control that project management provides, a project is more likely to have problems with one of these areas. A problem with only one constraint (scope, schedule, cost, resources, quality, and risk) can jeopardize the entire project." (Sandra F Rowe, "Project Management for Small Projects" 3rd Ed., 2020)

19 December 2012

Project Management: Quality (Just the Quotes)

"Managers jeopardize product quality by setting unreachable deadlines. They don’​​​​​​t think about their action in such terms; they think rather that what they’​​​​​​re doing is throwing down an interesting challenge to their workers, something to help them strive for excellence." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"People under time pressure don’​​​​​​t work better - ​​​​​​they just work faster. In order to work faster, they may have to sacrifice the quality of the product and of their own work experience." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The [software] builders’​​​​​​ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the quality of the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past. This is invariably a higher standard than what the market requires and is willing to pay for." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Issues of quality, timeliness and change are the conditions that are forcing us to face up to the issues of enterprise architecture. The precedent of all the older disciplines known today establishes the concept of architecture as central to the ability to produce quality and timely results and to manage change in complex products. Architecture is the cornerstone for containing enterprise frustration and leveraging technology innovations to fulfill the expectations of a viable and dynamic Information Age enterprise." (John Zachman, "Enterprise Architecture: The Issue of The Century", 1997)

"The aim of leadership should be to improve the performance of man and machine, to improve quality, to increase output, and simultaneously to bring pride of workmanship to people. Put in a negative way, the aim of leadership is not merely to find and record failures of men, but to remove the causes of failure: to help people to do a better job with less effort." (W Edwards Deming, "Out of the Crisis", 2000)

"Stakeholder management to me is key, as success or failure is in the eye of the beholder. Time, cost and quality fall prey to the perceptions of the key stakeholders, who may have nothing to do with the running of the project." (Peter Parkes, "NLP for Project Managers", 2011)

"Complexity is one of the causes of failing projects; failing to split the project into smaller tasks also causes software quality issues or project failure. Complexity can also be caused by the size of the  project; if the project is too big, there is a huge possibility that the project may become complex and complicated." (Abu S Mahfuz,"Software Quality Assurance", 2016)

"A project is usually considered a failure if it is late, is over budget, or does not meet the customer’s expectations. Without the control that project management provides, a project is more likely to have problems with one of these areas. A problem with only one constraint (scope, schedule, cost, resources, quality, and risk) can jeopardize the entire project." (Sandra F Rowe, "Project Management for Small Projects" 3rd Ed., 2020)

18 December 2012

Project Management: Estimation (Just the Quotes)

"Programmers seem to be a bit more productive after they’​​​​​​ve done the estimate themselves, compared to cases in which the manager did it without even consulting them." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"[The common definition of estimate is] 'the most optimistic prediction that has a non-zero probability of coming true' [...] Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished estimating" (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Because one has to be an optimist to begin an ambitious project, it is not surprising that underestimation of completion time is the norm." (Fernando J Corbató, "On Building Systems That Will Fail", 1991)

"Be sure you understand whether you're presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Don't expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can't accurately estimate an out-of-control process." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Not all estimation methods are equal. When looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

05 December 2012

Quality Management: Quality (Just the Quotes)

"Quality is never an accident; it is always the result of intelligent effort." (John Ruskin, "Seven Lamps of Architecture", 1849)

"It is most important that top management be quality-minded. In the absence of sincere manifestation of interest at the top, little will happen below." (Joseph M Juran, "Management of Inspection and Quality Control", 1945)

"Data are of high quality if they are fit for their intended use in operations, decision-making, and planning." (Joseph M Juran, 1964)

"The management of a system has to deal with the generation of the plans for the system, i. e., consideration of all of the things we have discussed, the overall goals, the environment, the utilization of resources and the components. The management sets the component goals, allocates the resources, and controls the system performance." (C West Churchman, "The Systems Approach", 1968)

"When a product is manufactured by workers who find their work meaningful, it will inevitably be a product of high quality." (Pehr G Gyllenhammar, "Management", 1976)

"Quality management is a systematic way of guaranteeing that organized activities happen the way they are planned." (Philip B Crosby, "Quality Is Free: The Art of Making Quality Certain", 1977)

"The problem of quality management is not what people don't know about it. The problem is what they think they do know." (Philip B Crosby, "Quality Is Free: The Art of Making Quality Certain", 1977)

"Uncontrolled variation is the enemy of quality." (W Edwards Deming, 1980)

"Almost all quality improvement comes via simplification of design, manufacturing, layout, processes and procedures." (Tom Peters, "Thriving on Chaos", 1987)

"Quality is a matter of faith. You set your standards, and you have to stick by them no matter what. That's easy when you've got plenty of product on hand, but it's another thing when the freezer is empty and you've got a truck at the door waiting for the next shipment to come off the production line. That's when you really earn your reputation for quality." (Ben Cohen, Inc. Magazine, 1987)

"Quality is very simple. So simple, in fact, that it is difficult for people to understand." (Roger Hale, "Quest for Quality", 1987)

"[...] running numbers on a computer [is] easier than trying to judge quality." (Esther Dyson, Forbes, 1987)

"The [quality control] issue has more to do with people and motivation and less to do with capital and equipment than one would think. It involves a cultural change." (Michael Beer, The Washington Post, 1987)

"Cutting costs without improvements in quality is futile." (W Edwards Deming, Forbes, 1988)

"Quality planning consists of developing the products and processes required to meet customer's needs." (Joseph M Juran, "Juran on planning for quality", 1988)

"Quality means meeting customers' (agreed) requirements, formal and informal, at lowest cost, first time every time." (Robert L Flood, "Beyond TQM", 1993)

"Many quality failures arise because a customer uses the product in a manner different from that intended by the supplier." (Joseph M Juran, "The quality planning process", 1999)

"Quality goals that affect product salability should be based primarily on meeting or exceeding market quality. Because the market and the competition undoubtedly will be changing while the quality planning project is under way, goals should be set so as to meet or beat the competition estimated to be prevailing when the project is completed." (Joseph M Juran, "The quality planning process", 1999)

"'Quality' means freedom from deficiencies - freedom from errors that require doing work over again (rework) or that result in field failures, customer dissatisfaction, customer claims, and so on." (Joseph M Juran, "How to think about quality", 1999)

"‘Quality’ means those features of products which meet customer needs and thereby provide customer satisfaction." (Joseph M Juran, "How to think about quality", 1999)

"The anatomy of 'quality assurance' is very similar to that of quality control. Each evaluates actual quality. Each compares actual quality with the quality goal. Each stimulates corrective action as needed. What differs is the prime purpose to be served. Under quality control, the prime purpose is to serve those who are directly responsible for conducting operations - to help them regulate current operations. Under quality assurance, the prime purpose is to serve those who are not directly responsible for conducting operations but who have a need to know - to be informed as to the state of affairs and, hopefully, to be assured that all is well." (Joseph M Juran, "How to think about quality", 1999)

"To attain quality, it is well to begin by establishing the 'vision' for the organization, along with policies and goals. Conversion of goals into results (making quality happen) is then done through managerial processes - sequences of activities that produce the intended results." (Joseph M Juran, "How to think about quality", 1999)

"Our culture, obsessed with numbers, has given us the idea that what we can measure is more important than what we can't measure. Think about that for a minute. It means that we make quantity more important than quality." (Donella Meadows, "Thinking in Systems: A Primer", 2008)

"A model is a representation in that it (or its properties) is chosen to stand for some other entity (or its properties), known as the target system. A model is a tool in that it is used in the service of particular goals or purposes; typically these purposes involve answering some limited range of questions about the target system." (Wendy S Parker, "Confirmation and Adequacy-for-Purpose in Climate Modelling", Proceedings of the Aristotelian Society, Supplementary Volumes, Vol. 83, 2009)

03 December 2012

Project Management: Project Management (Just the Quips)

Change Management

"Anything that can be changed will be changed until there is no time left to change anything."

"Change is inevitable - except from vending machines."

"If project content is allowed to change freely the rate of change will exceed the rate of progress."

"There is no such thing as scope creep, only scope gallop."

Cost Management

"A project ain't over until the fat cheque is cashed."

"Fast - cheap - good: you can have any two."

"For a project manager overruns are as certain as death and taxes."

[Juhani's Law:] "The cost of a compromise will always be more than that of either of the uncompromised alternatives."

"The more ridiculous the deadline the more money will be wasted trying to meet it."

Project Execution

"Activity is not achievement."

"Furious activity does not necessarily equate to progress and is no substitute for understanding."

"Good control reveals problems early - which only means you'll have longer to worry about them."

"If it happens once it's ignorance, if it happens twice it's neglect, if it happens three times it's policy."

"If you can interpret project status data in several different ways, only the most painful interpretation will be correct."

"If you don't know how to do a task, start it, then ten people who know less than you will tell you how to do it."

"Nothing is impossible for the person who doesn't have to do it."

"The person who says it will take the longest and cost the most is the only one with a clue how to do the job."

Project Managers

"A project is one small step for the project sponsor, one giant leap for the project manager."

"All project managers face problems on Monday mornings - good project managers are working on next Monday's problems."

"Everyone asks for a strong project manager - when they get him they don't want him."

"Good project management is not so much knowing what to do and when, as knowing what excuses to give and when."

"Good project managers admit mistakes: that's why you so rarely meet a good project manager."

"Good project managers know when not to manage a project."

"If you're 6 months late on a milestone due next week but nevertheless really believe you can make it, you're a project manager."

"There are no good project managers - only lucky ones."

"Overtime is a figment of the naïve project manager's imagination."

"Powerful project managers don't solve problems, they get rid of them."

"The most successful project managers have perfected the skill of being comfortable being uncomfortable."

"The most valuable and least used PHRASE in a project manager's vocabulary is "I don't know"."

"The most valuable and least used WORD in a project manager's vocabulary is "NO"."

Project Planning 

"A badly planned project will take three times longer than expected - a well planned project only twice as long as expected."

"A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied."

"A minute saved at the start is just as effective as one saved at the end."

"Any project can be estimated accurately (once it's completed)."

Fyfe's Laws: (1) Information necessitating a change in plans will be communicated to the planner after - and only after - the plans are complete. (2) The more innocuous the change in plans appears the great the change will actually be. (3) It is always simpler to start over from scratch than make changes in a plan already started. (4) The more carefully and painstakingly a sample is analyzed the greater the probability it will be found irrelevant.

"If everything is going exactly to plan, something somewhere is going massively wrong."

"If everything seems to be going well, you obviously don't know what's going on.” (Edward Murphy)

"If you can keep your head while all about you are losing theirs, you haven't understood the plan."

"No plan ever survived contact with the enemy."

"If it wasn't for the 'last minute' nothing would get done."

"If you don't know where you're going, any road will take you there."

"If you don't plan, it doesn't work. If you do plan, it doesn't work either. Why plan!"

"If you fail to plan you are planning to fail."

"If you have time to do it over again, you'll never get away with doing it right the first time."

"If you want to make God laugh have a definite plan."

"Never put off until tomorrow what you can leave until the day after."

"People make a plan work, a plan alone seldom makes people work."

"Planning is an unnatural process, doing something is much more fun."

"Planning reduces uncertainty: you rule out at least one way the project could turn out."

"Planning without action is futile, action without planning is fatal."

"Quantitative project management is for predicting cost and schedule overruns well in advance."

"Some projects finish on time in spite of project management best practices."

"The first 90% of a project takes 90% of the time the last 10% takes the other 90%."

"The more you plan the luckier you get."

"The nice thing about no planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."

"The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times."

"The sooner you get behind schedule, the more time you have to make it up."

"There is such a thing as an unrealistic timescale."

"There's never enough time to do it right first time but there's always enough time to go back and do it again."

"To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project."

"Warning: dates in the calendar are closer than you think."


"A project gets a year late one day at a time."

"At some point in the project you're going to have to break down and finally define the requirements."

"At the heart of every large project is a small project trying to get out."

[Gordon's First Law:] "If a project is not worth doing at all, it's not worth doing well."

"If an IT project works the first time, it is wrong."

"No project has ever finished on time, within budget, to requirement - yours won't be the first to."

"Projects happen in two ways: a) Planned and then executed or b) Executed, stopped, planned and then executed."

"Projects don't all fail in the end, they fail at the beginning."

"The project would not have been started if the truth had been told about the cost and timescale."

"There is no such thing as an IT project only business projects some of which happen to involve IT."

Risk Management

"A little risk management saves a lot of fan cleaning."

"If you don't attack the risks, the risks will attack you."

Senior Management

"Never underestimate the ability of senior management to buy a bad idea and fail to buy a good idea."

"The typical project sponsor would rather starts ten projects than complete one single project. (Vrisou van Eck)

10 November 2012

Data Migration: Data Quality’s Perspective I (A Bird’s-Eye View)

Data Migration

    Imagine you just finished a Data Migration (DM) project, everything went smoothly, the data were loaded into the new system with a minimum amount of issues, inherent sometimes to such complex projects, the users started to use the new system, everybody seemed to be satisfied, and a few weeks later within the company rumors propagate with the speed of light – “the migrated data are wrong”, “the new system can’t be used” , “IT did a bad job”, “we have to get back to the previous system”, and so on. The panic propagates, a few heads fall, the business tries to revert to the old system but there’s lot of new data available in the new system, and it’s not so trivial to move the data back to the old, in the meantime other rumors appear, and… it’s just a scenario but this could happen to any company if not the appropriate measures were taken at the right time. What could help a company when something like this happens?! A good Plan B aka a good Migration Fallback Plan/Policy, but that’s something nobody would like to do except extreme situations.

    A common approach to any type of projects as well to a DM project is to identify and mitigate the risks before or during the project. That’s something I started to do a few days ago, to prepare a list with the risks associated with DM projects. For this exercise I tried to remember what things went wrong in previous similar projects I worked on and to figure out what else could go wrong. Some online resources helped me to refresh my memory too, and I think I found also two or three things I haven’t really thought about. My attempt was primarily focused on this type of problem mentioned above – minimizing the risks of not having the right data when the new system goes live. Before jumping into the thematic I would like to sketch the bigger picture, as I perceive it.

    Having the right data when a system goes live primarily means having good Data Quality (DQ) in the target system after the data were migrated! As a DM is the best exemplification of the GIGO (Garbage-In Garbage-Out) principle, in order to have good DQ in the target is important to handle DQ latest during the DM project. That’s essential and common sense – you can’t expect to have good data in the new system when there’s lot of garbage in the old. So, a DM and a Risk Management for such a project should be built around this. In fact not having a DQ initiative or project in a DM project is one of the most important risks a company can take. Maybe in small DM, a DQ initiative isn’t necessary, though when the data are important for your company, DQ is a must! In addition DQ assessments have to be performed in alignment with the new system, and not the old. Even if the data have good quality into the old system, the quality of your data after DM will be judged in corroboration with the new system. This is a requirement that can be easily overlooked and its implications misunderstood!

    Many think that DQ is one time activity, we do it for a DM project and we’ll have quality data and never have to care about their quality anymore. Totally false! DQ has to be part of a broader strategy, call it Data Governance, Master Data Management, Data Management or any other initiative in which data plays an important role. DQ is an on going, iterative and consolidated effort, it doesn’t end after DM but continues for the whole data life-cycle, as long the data have value for an organization. It doesn’t help if the data have high quality when the data are migrated and a few weeks or months later the overall quality and trust in data decreased considerably.

    Keeping an acceptable level of DQ must be an organization’s strategy, and must be built a culture toward DQ. People need to be aware of the importance of having good quality data, and especially the consequences of having bad quality data. DQ doesn’t concern only the owners or stewards of data, or the people working with data, it concerns the whole organization because decisions are made based on those data, processes are changed and improved, an organization’s performance is often judged based on data. The quality of data is a matter of perception, on how users see the quality of data in corroboration with the needs they have, and the needs change over time. Primarily being aware what good DQ means and which are an organization’s needs in respect to data, it’s also a way of minimizing the negative perception of data, of gaining trust in data and some solid basis on which decisions can be made. Secondarily, these organizational data needs need to be addressed in a DM, they are the success factors upon which the success of a DM project is judged.

    For sure considerable costs are associated with DQ initiatives and everything related to data which doesn’t always represent a direct cost component in the products or services handled by an organization. Considering that not all data have the same importance for an organization, it makes sense to prioritize the DQ effort as a whole and the data cleaning needs in particular, the focus should be the data with the highest impact and with time to tackle data with lower and lower impact. It must be found equilibrium between the DQ costs and the value of data. Most probably is important to spend resources on raising people’s awareness in respect to DQ early rather than cleaning retroactively data later. It also make sense to invest in tools that help to clean data using automated or semi-automated methods, though some manual/visual control need to be in place too.

    DQ and the way the problems associated with it are tackled depends more on an organization’s internal kitchen – people, partners, organization, strategy, maturity, culture, geography, infrastructure, methodologies used, etc. What it matters is how the various negative and important aspects of an organization are aligned in order to take advantage of one of the most important assets an organization has is its data! For this is important to adopt methodologies that support DQ, align them and tweak them as requested, in order to make most of your data! But before or while doing that remember that a DM is an organization’s opportunity to change the quality of its data and its data strategy!

30 October 2012

Programming: Framework (Definitions)

"Unifying, guiding architectural approach, as in the data warehouse bus architecture." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit" 2nd Ed., 2002)

"A collection of classes, functions, protocols, documentation, and header files and other resources that are all related." (Stephen G Kochan, "Programming in Objective-C", 2003)

"A set of collaborating abstract and concrete classes that may be used as a template to solve a related family of problems. It is usually extended via subclassing for application-specific behavior." (Craig Larman, "Applying UML and Patterns", 2004)

"A coherent architecture that provides an incomplete template for systems within a specific domain; a coherent set of design patterns." (Bruce P Douglass, "Real-Time Agility", 2009)

"A support structure for developing software products." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"1.Generally, a basic skeletal structure. 2.Conceptually, a classification scheme used to better understand a topic; a defined and documented paradigm, used as a lens to view a complex problem. 3.In software development, a reusable object-oriented design, including a library of reusable classes and other components, along with standards for designing additional components and how they interact." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A support structure for developing and managing software products." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"A structure for supporting something else." ( Manish Agrawal, "Information Security and IT Risk Management", 2014)

"A support structure for developing and managing software." (Judith S Hurwitz, "Cognitive Computing and Big Data Analytics", 2015)

"A conceptual set of rules and ideas that provide structure to a complex and challenging situation." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A framework is a set of concepts that provide the basic structure for understanding a domain, enabling a common vocabulary for different explanatory theories." (Robert J Glushko, "The Discipline of Organizing: Professional Edition" 4th Ed., 2016)

25 October 2012

Programming: Assertion (Definitions)

"A constraint that is not attached to a table but is instead a distinct database object. It can therefore be used to enforce rules that apply to multiple tables or to verify that tables are not empty." (Jan L Harrington, "SQL Clearly Explained" 3rd Ed., 2010)

"A declaration or statement, often without support." (Janice M Roehl-Anderson, "IT Best Practices for Financial Managers", 2010)

"A statement about a program that the code claims to be true." (Rod Stephens, "Start Here!™ Fundamentals of Microsoft® .NET Programming", 2011)

"A statement that the code claims is true. If the statement is false, the program stops running so you can decide whether a bug occurred." (Rod Stephens, "Stephens' Visual Basic® Programming 24-Hour Trainer", 2011)

"A component of a regular expression that must be true for the pattern to match but does not necessarily match any characters itself. Often used specifically to mean a zero-width assertion." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A statement about the program and its data that is supposed to be true. If the statement isn’t true, the assertion throws an exception to tell you that something is wrong." (Rod Stephens, "Beginning Software Engineering", 2015)

"A language feature used to test for conditions that should be guaranteed by program logic. If a condition checked by an assertion is found to be false, a fatal error is thrown. For added performance, assertions can be disabled when an application is deployed." (Daniel Leuck et al, "Learning Java" 5th Ed., 2020)

"A way of ensuring that a method has access to a particular resource, even if the method's callers do not have the required permission. During a stack walk, if a stack frame asserting the required permission is encountered, a security check for that permission will succeed without proceeding further. To perform an assertion of a permission, code must not only have that permission, but also be granted the SecurityPermission.Assertion permission. Unwise use of assertions can create security holes, so they should be used only with the utmost caution." (Damien Watkins et al, "Programming in the .NET Environment", 2002)

24 October 2012

Programming: Assembly (Definitions)

"An assembly is the unit of deployment and versioning in the .NET Framework. An assembly contains a manifest, metadata, MSIL, and possibly binary resources. Most assemblies are single files, but an assembly can consist of multiple files, such as DLLs, picture files, and even HTML files." (Adam Nathan, ".NET and COM: The Complete Interoperability Guide", 2002)

"The unit of deployment and versioning in the .NET Framework. It establishes the namespace for resolving requests for types and determines which types and resources are exposed externally and which are accessible only from within the assembly. An assembly includes an assembly manifest that describes the assembly's contents." (Damien Watkins et al, "Programming in the .NET Environment", 2002)

"A managed application module that contains class metadata and managed code as an object in SQL Server. By referencing an assembly, CLR functions, CLR stored procedures, CLR triggers, user-defined aggregates, and user-defined types can be created in SQL Server." (Thomas Moore, "MCTS 70-431: Implementing and Maintaining Microsoft SQL Server 2005", 2006)

"A managed application module, composed of class metadata and managed code, that can be embedded in a database solution as a database object in SQL Server 2005." (Marilyn Miller-White et al, "MCITP Administrator: Microsoft® SQL Server™ 2005 Optimization and Maintenance 70-444", 2007)

"Application logic that is stored in, and managed by, the SQL Server database server, including objects like triggers, CLR software, and stored procedures. Assemblies are written in a .NET language, such a C# or Visual Basic." (Robert D. Schneider and Darril Gibson, "Microsoft SQL Server 2008 All-In-One Desk Reference For Dummies", 2008)

"In SQL Server, a .NET assembly is a compiled SQL CLR executable or DLL." (Michael Coles, "Pro T-SQL 2008 Programmer's Guide", 2008)

"A managed application module that contains class metadata and managed code." (Jim Joseph et al, "Microsoft® SQL Server™ 2008 Reporting Services Unleashed", 2009)

"In .NET applications, the smallest self-contained unit of compiled code. An assembly can be a complete application, or a library that can be called by other applications." (Rod Stephens, "Start Here!™ Fundamentals of Microsoft® .NET Programming", 2011)

"The smallest independent unit of compiled code. Typically, this is a Dynamic Link Library (DLL) or executable program." (Rod Stephens, "Stephens' Visual Basic® Programming 24-Hour Trainer", 2011)

"A managed application module containing class metadata and managed code as an object in SQL Server, against which CLR functions, stored procedures, triggers, user-defined aggregates, and user-defined types can be created in SQL Server." (Microsoft, "SQL Server 2012 Glossary", 2012)

"In SQL Server, a .NET assembly is a compiled SQL CLR executable or DLL." (Jay Natarajan et al, "Pro T-SQL 2012 Programmer's Guide" 3rd Ed., 2012)

"The fundamental logical unit of managed code, consisting of one or more files containing Common Intermediate Language instructions and metadata. See also CIL." (Mark Rhodes-Ousley, "Information Security: The Complete Reference" 2nd Ed., 2013)

23 October 2012

Programming: Array (Definitions)

"A group of cells arranged by dimensions. A table is a two-dimensional array in which the cells are arranged in rows and columns, with one dimension forming the rows and the other dimension forming the columns. A cube is a three-dimensional array and can be visualized as a cube, with each dimension of the array forming one edge of the cube." (Microsoft Corporation, "Microsoft SQL Server 7.0 Data Warehouse Training Kit", 2000)

"A collection of objects all of the same type." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"A list of variables that have the same name and data type." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"Values whose members, called elements, are accessed by an index rather than by name. An array has a rank that specifies the number of indices needed to locate an element (sometimes called the number of dimensions) within the array. It may have either zero or nonzero lower bounds in each dimension." (Damien Watkins et al, "Programming in the .NET Environment", 2002)

"A collection of data items, all of the same type, in which each item is uniquely addressed by a 32-bit integer index. Java arrays behave like objects but have some special syntax. Java arrays begin with the index value 0." (Marcus Green & Bill Brogden, "Java 2™ Programmer Exam Cram™ 2 (Exam CX-310-035)", 2003)

"A device that aggregates large collections of hard drives into a logical whole." (Tom Petrocelli, "Data Protection and Information Lifecycle Management", 2005)

"An arithmetically derived matrix or table of rows and columns that is used to impose an order for efficient experimentation. The rows contain the individual experiments. The columns contain the experimental factors and their individual levels or set points." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"A data structure containing an ordered list of elements—any Ruby object—starting with an index of 0." (Michael Fitzgerald, "Learning Ruby", 2007)

"An arithmetically derived matrix or table of rows and columns that is used to impose an order for efficient experimentation. The rows contain the individual experiments. The columns contain the experimental factors and their individual levels or set points." (Lynne Hambleton, "Treasure Chest of Six Sigma Growth Methods, Tools, and Best Practices", 2007)

"In a SQL database, an ordered collection of elements of the same data type stored in a single column and row of a table." (Jan L Harrington, "SQL Clearly Explained" 3rd Ed., 2010)

"A group of values stored together in a single variable and accessed by index." (Rod Stephens, "Stephens' Visual Basic® Programming 24-Hour Trainer", 2011)

"A grouping of similar items of the same storage type in a sequential pattern, and referenced by a sequential index value." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A variable that holds a series of values with the same data type. An index into the array lets the program select a particular value." (Rod Stephens, "Start Here!™ Fundamentals of Microsoft® .NET Programming", 2011)

"An ordered collection of values. Arrays can be defined as a basic Objective-C type and are implemented as objects under Foundation through the NSArray, and NSMutableArray classes." (Stephen G Kochan, "Programming in Objective-C" 4th Ed., 2011)

"A basic collection of values that is a sequence represented by a single block of memory. Arrays have efficient direct access, but do not easily grow or shrink." (Mark C Lewis, "Introduction to the Art of Programming Using Scala", 2012)

"An ordered sequence of values, stored such that you can easily access any of the values using an integer subscript that specifies the value’s offset in the sequence." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A group of variables stored under a single name." (Matt Telles, "Beginning Programming", 2014)

"A structure composed of multiple identical variables that can be individually addressed." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"A structure that contains an ordered collection of elements of the same data type in which each element can be referenced by its index value or ordinal position in the collection. See also element, ordinary array." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"An array is a data structure where elements are associated with an index. They are implemented differently in different programming languages." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

05 October 2012

Data Management: Business Rules – An Introduction

    "Business rules" seems to be a recurring theme these days – developers, DBAs, architects, business analysts, IT and non-IT professionals talk about the necessity to enforce them in data and semantic models, information systems, processes, departments or whole organizations. They seem to affect the important layers of an organization. In fact the same business rule can affect multiple levels either directly, or indirectly through the hierarchical or networked structure of causality it belongs to. When considered all the business rules, the overall picture can become very complex. The fact that there are multiple levels of interconnected layers, with applications and implications at macro or micro level, makes the complexity to fight back because in order to solve business-specific problems often you have to go at least one level above the level where the problems were defined, or to simplify the problems to a level of detail that allows to tackled.

    The Business Rules Group defines a business rule as "a statement that defines or constrains some aspect of the business" [1], definition which seems to be closer to the vocabulary of IT people. Ronald G. Ross, in his book Principles of the Business Rule Approach, defines it as "a directive intended to influence or guide business behavior" [2], definition closer to the vocabulary of HR people. In fact the two definitions are kind of similar, highlighting the constrictor or guiding role of business rules. They raise also an important question – can everything that is catalogued as constraint or guidelines considered as a business rule? In theory yes, practically there are constraints and guidelines that have different impact on the business, so depending on context they need to be considered or not. What to consider is itself an art, which adds up to the art of problem solving.

    Besides identification, neither the definition nor management of business rules seems easy tasks. R.G. Ross considers that business rules need to be written and made explicit, expressed in plain language, independent of procedures and workflows, built on facts, motivated by identifiable and important business factors, accessible to authorized parties, specific, single sourced, managed, specified by those people who have relevant knowledge, and they should guide or influence behavior in desired ways [2]. This summarizes the various aspects that need to be considered when defining and managing business rules. Many organization seems to be challenged by this, and it can be challenging when lacks business management maturity.

    Many business rules exist already in functional and technical specifications written for the various software products built on request, in documentation of purchases software, in processes, procedures, standards, internal defined and external enforced policies, in the daily activities and knowledge exchanged or hold by workers. Sure, the formulations existing in such resources need to be enhanced and aggregated in order to be brought at the status of business rule. And here comes the difficulty, as iterative work needs to be performed in order to bring them to the level indicated by R.G Ross. For sure Ross’ specifications are idealistic, though they offer a “framework” for defining business rules. In what concerns their management, there is a lot to be done within an organization, as this aspect needs to be integrated with other activities and strategies existing in an organization.

    Often, when an important initiative, better said project, starts within an organization, then is felt in particular the lack of up-front defined and understood business rules. Such events trigger the identification and elicitation of business rules; they are addressed in documentation and remain buried in there. It is also true that it’s difficult to build a business case for further processing of business rules. An argument could be the costs associated from decisional mistakes taken by not knowing the existing rules, though that’s something difficult to quantify and make visible in an organization. In the end, most probably an organization will recognize the value of business rules when it reached a certain level of maturity.

[1] Business Rules Group (2000) Defining Business Rules - What Are They Really? [Online] Available from: http://businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf
[2] Ronald G. Ross (2003) Principles of the Business Rule Approach. Addison Wesley. ISBN: 0-201-78893-4.

29 September 2012

Programming: Pair Programming (Definitions)

"An XP practice requiring that each piece of source code to be integrated into the software product should be created by two programmers jointly at one computer."" (Johannes Link & Peter Fröhlich, "Unit Testing in Java", 2003)

"A coding technique where one programmer (the driver) writes code and explains what he or she is doing, while another watches and looks for problems." (Rod Stephens, "Start Here!™ Fundamentals of Microsoft® .NET Programming", 2011)

"A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews are performed." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"An Extreme Programming practice where two (or three) programmers work together at the same computer. The driver or pilot types while the observer, navigator, or pointer watches and reviews each line of code as it is typed." (Rod Stephens, "Beginning Software Engineering", 2015)

"A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews are performed." (SQA)

25 September 2012

Programming: BLOB (Definitions)

"A type of data column containing binary data such as graphics, sound, or compiled code. This is a general term for text or image data type. BLOBs are not stored in the table rows themselves, but in separate pages referenced by a pointer in the row." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"BLOB is a data type for fields containing large binary data such as images." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"A binary large object. Large value data types [varchar(max), nvarchar(max), and varbinary(max)] are stored as BLOBs. Within SQL Server 2005, BLOBs can be as large as 2GB." (Darril Gibson, "MCITP SQL Server 2005 Database Developer All-in-One Exam Guide", 2008)

"A data type that can hold large objects of arbitrary content such as video files, audio files, images, and so forth. Because the data can be any arbitrary chunk of binary data, the database does not understand its contents so you cannot search in these fields." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"Binary large object (BLOB) data is data that is stored using the varbinary(max) data type. A BLOB column or variable can hold up to 2.1 GB of data, as opposed to a regular non-LOB varbinary or binary column or variable, which can max out at 8,000 bytes of data." (Michael Coles & Rodney Landrum, , "Expert SQL Server 2008 Encryption", 2008)

"Very large binary representation of multimedia objects that can be stored and used in some enhanced relational databases." (Paulraj Ponniah, "Data Warehousing Fundamentals for IT Professionals", 2010)

"A discrete packet of binary data that has an exceptionally large size, such as pictures or audio tracks stored as digital data, or any variable or table column large enough to hold such values. The designation 'binary large object' typically refers to a packet of data that is stored in a database and is treated as a sequence of uninterpreted bytes." (Microsoft, "SQL Server 2012 Glossary", 2012)

"A large assemblage of binary data (e.g., images, movies, multimedia files, even collections of executable binary code) that are associated with a common group identifier and that can, in theory, be moved (from computer to computer) or searched as a singled data object. Traditional databases do not easily handle BLOBs." (Jules H Berman, "Principles of Big Data: Preparing, Sharing, and Analyzing Complex Information", 2013)

"A blob is any resource whose internal structure is functionally opaque for the purpose at hand." (Robert J Glushko, "The Discipline of Organizing: Professional Edition" 4th Ed., 2016)

24 September 2012

Programming: Block (Definitions)

"A series of statements enclosed by BEGIN and END. Blocks define which set of statements will be affected by control-of-flow language such as IF or WHILE. You can nest BEGIN...END blocks within other BEGIN... END blocks." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A section of code grouped together by braces that sets apart a section of code in a smaller area than a full procedure. A procedure might contain several blocks of code." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours 2nd Ed.", 2001)

"A sequence of PL/SQL code, beginning with DECLARE or BEGIN and ending with END. The block is a core organizational unit of PL/SQL programming. See Chapter 2 for a thorough discussion." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"A series of Transact-SQL statements enclosed by BEGIN and END. You can nest BEGIN...END blocks within other BEGIN...END blocks." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"A syntactic construct consisting of a sequence of Perl statements that is delimited by braces. The if and while statements are defined in terms of BLOCKs, for instance. Sometimes we also say 'block' to mean a lexical scope; that is, a sequence of statements that acts like a BLOCK, such as within an eval or a file, even though the statements aren’t delimited by braces." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A Transact-SQL statement enclosed by BEGIN and END." (Microsoft, "SQL Server 2012 Glossary", 2012)

"The information stored in a sector" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"A set of rows retrieved from a database server that are transmitted as a single result set to satisfy a cursor FETCH request." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

03 August 2012

Quality Management: Total Quality Management (Definitions)

"A concept that focuses on managing the total organization to deliver quality to customers. Four significant elements of TQM are employee involvement, focus on the customer, benchmarking, and continuous improvement." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A management concept (and associated tools) that involves the entire workforce in focusing on customer satisfaction and continuous improvement." (Martin J Eppler, "Managing Information Quality" 2nd Ed., 2006)

"A management strategy aimed at embedding awareness of quality in all organizational processes." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed., 2011)

"Procedures and policies aimed at organization-wide continuous improvement." (Leslie G Eldenburg & Susan K Wolcott, "Cost Management 2nd Ed", 2011)

"Techniques, methods and management principles for continuous improvement, based on the work of Deming, Juran, Crosby and others." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A management philosophy based on the premise that the quality of products and processes can be continuously improved." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"A philosophy and a set of principles that set the stage for a continuously improving organization." (Joan C Dessinger, "Fundamentals of Performance Improvement" 3rd Ed., 2012)

"A management philosophy from the 1940s and 1950s, consisting of various strategies to ensure quality products and services." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"A comprehensive approach to the management of quality from the production environment that proves that the costs of preventive quality management exceed the total costs for all reactive measures in the management of quality. This applies to material, as well as immaterial, goods like data." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"A holistic approach to long-term success that views continuous improvement in all aspects of an organization as a process and not as a short-term goal." (Kijpokin Kasemsap, "Applying Lean Production and Six Sigma in Global Operations", 2016)

"A systematic, organization-wide approach to quality that stresses continually improving all processes that deliver products and services, with the major outcome of 'delighting' the customer." (Atila Ertas, "Transdisciplinary Engineering Design Process", 2018)

"An organization-wide management approach centered on quality, based on the participation of all members of the organization and aiming at long-term success through customer satisfaction, and benefits to all members of the organization and to society. Total Quality Management consists of planning, organizing, directing, control, and assurance. (ISO 8402)

Quality Management: Cost of Quality (Definitions)

"Cost of poor quality is the cost associated with providing poor-quality products or services. There are four categories: internal failure costs (costs associated with defects found before the customer receives the product or service), external failure costs (costs associated with defects found after the customer receives the product or service), appraisal costs (costs incurred to determine the degree of conformance to quality requirements), and prevention costs (costs incurred to keep failure and appraisal costs to a minimum)." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"A method of determining the costs incurred to ensure quality. Prevention and appraisal costs (cost of conformance) include costs for quality planning, quality control (QC), and quality assurance to ensure compliance to requirements (i.e., training, QC systems, etc.). Failure costs (cost of non-conformance) include costs to rework products, components, or processes that are non-compliant, costs of warranty work and waste, and loss of reputation. " (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"Costs incurred to insure high quality and/or the actual and opportunity costs from problems with poor quality. Also see quality-related activities." (Leslie G Eldenburg & Susan K Wolcott, "Cost Management 2nd Ed", 2011)

"Money spent during the project to avoid failures, including prevention and testing costs. COQ operates on the premise that costs for meeting quality requirements are less than those for dealing with nonconformance to requirements." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"All costs incurred over the life of the product by investment in preventing nonconformance to requirements, appraisal of the product or service for conformance to requirements, and failure to meet requirements." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK Guide )", 2017)

"The total costs incurred on quality activities and issues and often split into prevention costs, appraisal costs, internal failure costs and external failure costs." (Software Quality Assurance)

06 July 2012

Project Management: Change Control Board (Definitions)

 "A group of project members, possibly including one or two customers, that reviews and approves or rejects change requests." (Rod Stephens, "Beginning Software Engineering", 2015)

"A committee that makes decisions regarding whether proposed changes to a system should be implemented." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"A central authority for the management of change requests." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"A formally constituted group of stakeholders responsible for reviewing, evaluating, approving, delaying, or rejecting changes to a project, with all decisions and recommendations being recorded." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

05 July 2012

Project Management: Project Manager (Definitions)

"The individual responsible for managing a project." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"The person responsible for managing a project." (Margaret Y Chu, "Blissful Data ", 2004)

"The person responsible for planning, directing, and controlling a project." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives." (Project Management Institute, "The Standard for Program Management" 3rd Ed., 2013)

"A professional who is responsible for managing a project’s pursuit of its intended outputs and/or outcomes. Project managers are operational leaders who are responsible for assuring that a project meets its operational goals for delivering work products with prescribed specifications - on time and on budget." (Richard J Heaslip, "Managing Complex Projects and Programs", 2014)

"Individual or body with authority, accountability and responsibility for managing a project to achieve specific objectives." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"The individual responsible for managing a project and its completion within its scope, budget, and schedule." (Christopher Carson et al, "CPM Scheduling for Construction: Best Practices and Guidelines", 2014)

"The person primarily responsible for managing a project to its successful completion." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"An organizational employee, representative, or consultant appointed to prepare project plans and organize the resources required to complete a project, prior to, during, and upon closure of the project life cycle." (H James Harrington & William S Ruggles, "Project Management for Performance Improvement Teams", 2018)

01 July 2012

Data Migration: An Introduction

Data Migration


    Basically, Data Migration is the movement of data from one IS (Information System), the legacy system, to a new IS, the target system, supposed to replace entirely or partially the legacy system. In the best scenario there are no differences between the two IS or the differences are minimal, negligible. In the worst scenario, there are multiple legacy systems used as source, and even multiple target systems, with important differences between them, differences that can even be translated in incompatibilities at multiple levels. Such architectures can span geographies, departments, organizations or industries; can involve a multitude of vendors, generations of systems, network types, different regulations, etc. In many Data Migrations the overall picture can be really complex, though for the sake of simplicity it’s enough to focus on the simplest scenario in which there is a single source and a single target system, with some differences between them. Abstraction can be made also of the fact that many migrations are parts of bigger projects, for example ERP implementations or any other type of applications migrations.

    Data Migration is quite a complex topic, for many appearing like a black box in which data come in and data come out. That’s valid for the typical user as well for the IT professionals who haven’t been involved in Data Migration projects. There are many books on topics that are tangent to Data Migration – Data Management, Data Quality, Data Integration or Data Warehousing. Excepting some presentations available on the Web, a few methodologies exposed by important companies, one or two books, and a few blogs, there isn’t much material available on Data Migration. The “trend” is also a reflection of the low importance given to Data Migration as subject, even if many professionals working in the field warn about the considerable impact a Data Migration can have on a project in particular, and on business in general.

    Approaching a topic like Data Migration can be, upon case, a complex task, however with a little intuition and some guidance its complexity falls apart. Often, when exploring such a topic, of help can be the 5W1H technique or its extended forms. The technique resumes to searching for answers to the “what”, “where”, “why”, “how”, “when”, “who” and “with what” questions. In case of Data Migration the questions are formulated as: what (data) to migrate, where to migrate, why to migrate, how to migrate, when to migrate, who migrates and with what to migrate?

Why to migrate?

    A Data Migration occurs as follow up of a need – an old system exists in place and can’t cope anymore with business’ growth, a company made an acquisition and the systems need to be consolidated, or the organization decided to change its infrastructure, the processes, the business model in order address nowadays business requirements like flexibility, availability, manageability, automation, cost cuts, etc. In other words a Data Migration occurs as a need for change, and it can be itself a change in what concerns technical infrastructure, process, procedures, data flow, ways of doing business. A migration has quite an impact on the business, so here is an entitled question: does it really makes sense to migrate? Why not start from 0 with the new system?!

    The migration can be a 0 point for an organization, though unless a company is starting anew, there are some data laying there in the old system(s) that need to be further available - for example open Purchase Orders that need to be fulfilled, Invoices that need to be paid, a catalog with all the Products and the available stock, information about Customers, what they bought, what they browsed or what they want to buy for Christmas, etc. At least some of the data need to be made available in one form and another also within the new architecture, if not the new system.

    The availability of old data can be solved by keeping the old system(s) in place, functional, even if the system won’t be fed with new data, or maybe it will. Keeping a system alive involves additional costs for maintaining the infrastructure – software and hardware licenses, consultants, administrators and other people responsible for the optimal work of such a system. This can become with time quite an unnecessary burden. It can be an acceptable choice for some organizations, but unlikely as best/good practice. And even if the system is kept, more likely there will be data that need to be available also in the new system. Can be discussed also about integration of the two systems, but again, does it make sense? The bottom line is that in multiple scenarios a Data Migration can prove to be the optimal solution for an organization.

What data to migrate?

    Even if it looks like a silly question, it can be one of most complex questions to answer. In theory is needed to migrate all the data, but are really needed all the data? Typically in a database can be found historical data not used anymore by the business, obsolete data marked or not for deletion, garbage data entered by mistake or remained after incomplete deletions, all these having low or no value for the business. Hopefully there are also “good data”, quintessential for the business. Somebody would say “what a hack, why do we need to philosophize so much, let’s migrate all the data!”. The decision can be understandable, though what if the percentage of “good data” is quite small in comparison with the total volume of data which can measure a few terabytes?! Sure, nowadays data centers can handle without problems terabytes of data, though there are some factors to be considered – it can be quite a challenge to migrate so many data, the volume of data affects also the performance of databases in particular, and IS in general, and a more natural reason – why store something that has minimal value for you?!

    It makes sense to migrate only the data that have value for an organization, but what data are needed then? Normally this starts by understanding what entities the business deals with and which are the attributes that characterizes them. Many of the entities can be met in organization’s daily activity, and maybe are already defined in organization’s glossary or Data Dictionary, so a review of the available inventory might do. If not, more effort needs to be spent for this purpose; activities specific to Data Discovery, Data Categorization, Data Definition or Data Profiling tasks can help after case to fill the understanding gaps. Except categorization the others are not all necessary, same as the analysis can be deep enough to serve the purpose.

    A first categorization was made above when data were considered as valuable, not valuable or in between. A second categorization can be made based on data’s usage: obsolete (not used anymore or marked for deletion), new (not used and recently entered), historical (data used in the past) and actual (data in use). A third categorization can be made on the status of the entities they represent, status that can be associated to the phase of the process the entity represent (e.g. active, inactive, open, invoices, closed, blocked, etc.). There can be considered other meaningful categorizations as long they prove to be important in identifying the useful data.

    An important categorization in migrations, in particular, and Data Management, in general, is to split data in master data, transaction data and setup data. Master data are data are data that change only seldom and have a long life (until become obsolete), are referenced through all the system, and are vital to an organization through their meaning (e.g. Customers, Suppliers, Products, Assets, Employees, Accounts, etc.). Transaction data in exchange are data that change often and have a relatively short life, typically are referenced by other transactions and can be associated with documents or movements through the system (e.g. Purchase Orders, Sales Orders, Invoices, Receipts, Assets Movements, etc.). Setup data are data used to configure a system (e.g. Transaction Types, Document Types, Roles, Permissions, etc.). This categorization deserves the full attention, because each of the three elements needs a different handling approach in migration or Data Management.

    Based on the identified categories can be considered some rough migration rules in deciding what data (actually records) to migrate, for example: - master data, unless they become obsolete, and open transactions are often considered to be migrated entirely; - historical transaction data spanning a few years back can be migrated in case they are needed in the process; - master data referenced by transaction data migrated need to be migrated too - setup data are entered manually - historical data are archived. There can be also exceptions from the rules, so such possible scenarios need to be considered too.

    Each entity is defined by multiple attributes (also called properties, dimensions). They need to go through a similar “categorization” process. In deciding what attributes to migrate is important to consider especially their role in defining the entity. Some of them define uniquely an entity (e.g. Customer Number, Product Number, Serial Number), physical characteristics of the entity (e.g. color, weight, height), categorize the entity (e.g. Category, Type) or its status (e.g. Active, Blocked, Invoiced), imply various events (e.g. Creation Date, Delivery Date, Invoice Date), and so on. It looks like another type of categorization, and it is, though it’s more difficult to create some rough rules based on it, because in the end the business dictates which Attributes are needed. In fact, most of the Attributes used (with distinct not null values) in the legacy system are more likely needed also in the new system, unless the process changed considerably, or the business is supposed to change also its model.

Where to migrate the data?

    When the Data Migration subject is brought on the table, a decision was already made about the target system. So the “where” question is partially answered, however it addresses only the peak of the iceberg. It shows that an iceberg lies there, in front of us, though under the deep of the waters there is something more, lot of questions and issues that need to be addressed. Like the source, the target needs to be further detailed in entities and their attributes; the targeted processes and procedures need to be considered together with the constraints imposed by the new system. It’s actually needed to identify the data requirements for the new systems and corroborate them with the requirements of the old system. Mapping the entities and attributes available in the two systems, process known as Data Mapping, can offer a good overview of what lays ahead, what similarities and gaps exist. There will be attributes that are available in the legacy but not in the target system, and therefore the target system needs to be extended or the data associated with the respective attributes can be left out. From the opposed perspective, there can be mandatory attributes in the target system which are not available in the organization, and therefore the associated data must be collected and/or made available for the migration. There can be cases when the data are not available in the legacy system but distributed in various other external or internal sources, so there can be an option to migrate or integrate the respective data, extend the processes to accommodate such scenarios, etc.

    Only when the mapping of data is ready and the various related questions addressed, the “where” question is fully answered. Given the continuous changes done to the target system that may still happen a few days before Go Live, Data Mapping can remain a hot topic until then.

With what to migrate?

    This question addresses the mix of tools used to migrate the data, and by extension the whole architecture developed for this purpose. As many experts point out, there is no general solution for such an approach because each migration is challenged by different requirements and architectures. ETL (Extract, Transform, Load) and Data Integration tools were mainly designed for this kind of purposes – moving data between data sources – therefore more likely the whole Data Migration architecture will be built around such a tool. In addition is needed to be addressed topics like assessment and reporting of Data Quality, Data Cleaning, Data Enrichment, Data Backup or Data Security. They will technically ensure that the data are migrated within intended level of quality and security.

    For each of these topics are available one or more tools on the market. The challenge is to find the right mixture for the overall architecture, to make them work together in an efficient and effective manner. One of the problems such tools have is that they look to the Data Migration or similar problems from their own perspective, making them hard to integrate with other tools. Given the increasing need for Data Migration, more likely exist there tools that cover most of its requirements, each with its own advantages and disadvantages. Starting with a new tool can prove to be quite challenge in itself. Many recommend following a methodology and using tools that already proved their capabilities in other projects. That’s a good approach, though need to be considered also costs, available resources, effort to build the infrastructure, the learning curve, etc. For some migrations MS Excel or Access will do, for others a more complex framework is needed. Keep in mind that there is no perfect architecture, just the architecture that will drive you to achieve your targets.

How to migrate the data?

    “How” refers mainly to the migration approach, steps, methodologies, processes and procedures used to migrate the data. Secondly, and not less important, it refers to how the mix of tools is used for migration – in other words the implementation. Despite the huge variety of tools and means of achieving the target, there can be depicted some generalities for each of these topics.

    Migration approach refers to the overall strategy considered for a migration – typically on whether the data are migrated all together, the new system becoming functional and replacing the legacy system (the big-bang migration), or the data are migrated in phases, the legacy and target systems functioning in parallel for a certain amount of time (the phased-out migration). Can be met other variations of migration approaches, under various denominations. It’s important to know the advantages and disadvantages of both or all approaches, especially in what concerns their application in your organization.

    “Steps” is just a misnomer for the actual Project Plan in which are considered the different phases and activities of such a project. In a general Data Migration project, can be discussed about Data Discovery, Data Definition, Data Collection, Data Consolidation, Data Mapping, Data Conversion, Data Transformation, Data Quality Assessment, Data Cleaning, Data Storage, etc. Some of these steps can be considered as standalone processes, sometimes being already part of the processes’ landscape existing in an organization. Other steps are just simple activities. Both types of steps share some important characteristics – they can be highly iterative and complex, are owned by the business, the IT functioning as facilitator, each of them depends on the input from other steps, and require continuous feedback, etc.

    A Data Migration is (should be) managed as any other IT project, and therefore can be discussed about project-specific methodologies like PMBOK, Prince2 or PRISM. Many of the before mentioned steps come with their luggage of methodologies too. In addition, considering that IT functions as a service, could be considered service-specific methodologies like ITIL, ISO/IEC, Six Sigma, etc.

    The actual implementation of all these depends entirely on the project’s scope, the knowledge of all those involved, the constraints met and the resources available for such a project. Many of the IT-specific problems and situations are specific across all IT projects.

Who will migrate the data?

    There is no Data Migration project that can be done without the business, the de facto owner of such a project and its output. There is lot of input needed from the business, its continuous involvement through the various stages is necessary for the whole duration. Unless the Data Migration resumes to a rudimentary tool like Excel and can be handled without too much expertise, a Data Migration needs technical resources that can elicit the requirements, translate them in technical requirements, built the infrastructure and maybe migrate the data. It entirely depends on the overall architecture and methodology what people are involved. In the best case scenario the migration will resume to one person pushing a button and the data flow as magic from source to the target system. In reality, multiple people will have to take care of migration, pushing some magic buttons in a chain of parallel and even redundant steps, monitoring and validating the process. Data owners, data stewards, data custodians, data architects, database administrators, migration and quality assurance specialists, developers, consultants and many other people can be involved, each of them playing their role.

When to migrate the data?

    Intuitively, data are or should be migrated when the target system is ready to receive the new data, thus when the development was finished, the system tested, and all the preparation for Data Migration were made. The statement is valid for any type of migration. How such a date or dates are calculated when a project starts is in itself kind of science or just a matter of needs. There are projects in which the dates for each milestone or phase are calculated back from a desired Go Live date, or projects in which the Go Live is calculated incrementally based on the steps to be performed. For dates’ calculation can be used also benchmarking from the field. The bottom line is that the data must be migrated on time for the Go Live and with a minimum disruption for the business.


    Whether standalone or as subproject of another project, a Data Migration can be or become quite a complex thematic that, through its outcomes, affects the business considerably. In the above paragraphs were considered some of the important aspects of such a project, the focus being more on figuring out what a migration implies rather than a detailed exploration. It’s also a mental exercise and an invitation into the thematic.

Related Posts Plugin for WordPress, Blogger...