In my industry, workflow is considered by many as a holy grail.  Most leaders of litigation support departments feel that they can control risks, issues, schedules, and quality through one comprehensive workflow or even a checklist.  It is tempting to think that a machine could orchestrate a project to such a degree of success that the humans involved cannot make errors.

Unfortunately, there is no perfect workflow in our industry.  Not a single litigation support manager I have spoken to feels that they have their hands around the problem.  And so, we look at vendor after vendor peddling their software with a state-of-the art workflow system built in.

So, why do these system's fail to achieve their promised goals?  Here is my list of "gotchas" about attempting to automate your project management functions via workflow:

• Poor planning - insufficient involvement by everyone involved with the system (IT, front-line employees, and management) during the early evaluation and planning stages of the implementation can lead to ballooning budgets and quirky systems forcing the employees to use workarounds and introduce all new and unknown risk into the process.
• Poor understanding of the limitations of workflow - it may handle human-to-human task management but when you add human-to-system and system-to-system interactions, event management/correlation, performance monitoring, change management, and process rules many systems just fall apart.
• Poor change management - sometimes the implementation of the workflow takes several months to complete.  Even with perfect planning at the beginning of an implementation, sometimes changes in the business outpace workflow development.  Many implementers fail to keep up with the pace business causing the delivered workflow to be out of date and unsuitable.
• No implementation with LOB applications - users touch many systems during a business process.  Many of these interactions are not documented anywhere.  A good workflow system needs to take into account integration with billing systems, case management systems, etc.
• Automating chaos - if your process is not clearly understood, defined, and optimized you will be automating chaos via workflow.  The result of this can only be "automated chaos."
• Forgetting the people -  sometimes it is important to understand that it is not all about nuts and bolts.  It may not be about the lack of Change Management or the way integration is done with LOB systems.  It’s about PEOPLE.  Involve the users, educate the users and get buy-in up-front, let the users champion the project direction, talk to the front-line employees and narrow the gap between IT techniques and the Business requirements.

Keep these things in mind if you insist on purchasing a system that attempts to automate your project management.  However, I recommend that litigation support managers look spend some time and optimize their people and process before they attempt to automate things.  Sometimes, the right people are all it takes.

Technorati Tags: project management, workflow, litigation support

Craig Brown of Better Projects wrote an excellent post highlighting the reasons why a client might prefer to work with certain people even though other equally qualified people are available.

"Patients will [...] cross the city to visit their preferred GP [rather than visiting the nearest available doctor]. Patients are not in a good position to assess the quality of medical advice they receive, so what makes them care enough about a doctor to make such efforts? The answer is the "bedside manner" which in the context of this [project management / consulting] is their empathy."

Project managers and consultants need to empathize with their client, their employees, and other stakeholders.  Through empathy, one can truly understand the issues that the other party is dealing with and respond with sincerity.

Once, I was involved in a project where the client services manager had to relay a possible budget overrun to the client.  Unfortunately, the client had been under the impression that the supplier would absorb any cost overruns.  The first course of action that the client services manager took is to explain in detail to the customer how high the quality of our services has been and pointed out relevant passages in the contract to correct the client's perception.  However, the client soured on the relationship feeling that he was being cheated.  When the issue was escalated, the executive from our company listened very carefully to the client's pain points and empathized with him.  This led directly to an improvement of the client relationship and contributed to a successful negotiation and follow-on work.

Do you have any stories where empathy or lack thereof led to a change in the client relationship?  If so, leave a comment.

 

In my previous article, Good Insights On Managing Knowledge Workers, I concluded that "Empowering an employee is the only way to harness the talent that the company has and is a very challenging feat."  However, this is only the first step in the process.  Since posting that entry, I have been researching the psychology of motivation.

In psychology, the process of learning new behaviors or responses as a result of their consequences is called conditioning.  I believe that the average employee has been conditioned to follow orders, to keep quiet, and do the minimum amount of work.  Through their experiences at previous jobs or projects, employees have picked up an attitude that prevents them from accepting empowerment even if given full authority to make their own decisions.

The first job of a project manager in this situation is to condition the employee to respond positively to empowerment.  The PM has to encourage positive behaviors and diminish the negative ones.  There are four commonly accepted methods of reinforcement to do just that:

 

• Positive Reinforcement. Something positive provided after a response in order to increase the probability of that response occurring in the future. For example, recognizing that an employee has stayed late last night and saying "thank you."  The most common types of positive reinforcement or praise and rewards, and most of us have experienced this as both the giver and receiver.
• Negative Reinforcement. Think of negative reinforcement as taking something negative away in order to increase a response. For example, nagging the employee to fill out his weekly timesheet on time until they start doing it automatically. The elimination of this negative stimulus is reinforcing and will likely increase the chances that the employee will fill out their timesheet next week.
• Punishment. Punishment refers to adding something aversive in order to decrease a behavior. The most common example of this is disciplining an employee for being late. The reason we do this is because the employee begins to associate being punished with the negative behavior. The punishment is not liked and therefore to avoid it, he or she will stop behaving in that manner.
• Extinction. When you remove something in order to decrease a behavior, this is called extinction. You are taking something away so that a response is decreased.  An example of this is removing an employees internet access to discourage them from playing games during work time.

Being aware of how our actions reinforce behaviors is something that project managers need to keep in mind.  Have you ever let an employee slide with a poor excuse in a status meeting?  If you have, you just used positive reinforcement with an undesired behavior.

 

Raven at Raven's Brain has posted a great quote regarding Good Insights On Managing Knowledge Workers that I think applies even more to the litigation support industry.  Litigation support is part of the information and support economy and most of the people in this industry are knowledge workers.  Knowledge workers are people who add value through their intellect rather than physical attributes.  Because knowledge workers use intellect rather than brawn, old techniques of managing users by just assigning tasks and jobs has become harder.  Workers are no longer doing one task at one workstation.  They have valuable skills that should be fostered and used in the best possible combination. 

"A good manager doesn't tell people what to do or how to accomplish their tasks, but removes roadblocks and makes the way clear [for employees to be] more productive.  [Another] important role that managers have is to identify and grow talent.  Unfortunately, many managers don't place enough emphasis on helping the individuals within their teams grow and improve their capabilities.  Ultimately, a manager [ONLY] succeeds when the people who reported to him grow into new capabilities and roles." -- Jeffrey Phillips at Think Faster

Managers who do not foster each knowledge worker's talents or hold on to the outdated "workers as resources" mantra will have a hard time keeping employees motivated in this industry.  Empowering an employee is the only way to harness the talent that the company has and is a very challenging feat.  That is something that I want to explore further in future posts.

How do you empower your employees?

Read the article on the Think Faster blog entitled "What's a manager to do?"
Read the article on Raven's Brain blog entitled "Good Insights On Managing Knowledge Workers"

Tags: Knowledge Workers, IT Management, Management, Litigation Support 

As a consultant, I visit many organizations and speak to them about project management. A large majority of managers who deal with small initiatives complain that project management methodologies are overkill for their project/organization. Furthermore, some use this logic to justify their lack of following any sort of project management processes or techniques. It is with these Project Managers in mind that I read Tom L. Barnett's A Small-Project Playbook article on ComputerWorld. An article that promised to find the solution for the manager of small projects.

In the article, Tom proposes that in such circumstances a Project Manager can use his Playbook "tool" to manage the project. The "tool," however, is nothing more than a chart consisting of "eight columns: Task Name, Description, Due Date, Owner, Issues, Deliverables, To, and Waiting On." Tom says this allows him to replace the WBS, meeting agendas, resource assignment matrix, and status reports.

However, I view this as a dangerous proposition when speaking to clients that are already weary of project management. The playbook is just a tool that will be rather useless in the hands of a person that does not already know the project management concepts that are used to populate it. Project management is a set of processes, not tools. Furthermore, it serves as a poor introduction to project management techniques for the beginner. Rather than learning proper project management and using critical thought to apply the appropriate techniques, beginners will learn bad habits right from the start. The tool does not even encourage a small project manager to split their activities into initiation, planning, execution, and closing. It transforms a project manager into a task master.

Rather than taking the less-than-ideal approach, beginners should focus on light-weight management methodologies like SCRUM, an agile methodology focused on small, cross-functional teams. From this, they will learn the benefits of setting up and following processes without burdening the organization with heavy frameworks. New project managers need to understand that success is more dependent on critical thinking and process than tools and technology. The bottom line is: neither the playbook nor Microsoft Project will make one a project manager.

For more information about Agile methodologies, see Raven's article Good List of Agile Program/Project Management Resources.

In his article "Expectations and Violations," Paul Glen discusses the human side of project failure. We consultants are often called in to a company as a last resort to save a failing project. Typically, this happens after a project has missed deadlines. The company realizes that the imminent failure of the project is not due to poor schedule or cost management but to human and business relationships.


I completely agree with Paul on this issue. It is nearly impossible to avoid poor project performance without considering human issues and expectations. Functional managers have dealt with human issues far longer than pure project managers. However, we must do our best to manager people as much as cost, schedule, and scope.

Do you have examples of projects that have failed because of human issues? Leave a comment.

According to a study by Dr. David P. Norton, of the Palladium Group and Cognos Corporation, nearly 90% of companies are having trouble executing their corporate strategy. However, the ten percent of companies that do manage to execute their strategies achieve dramatic benefits. If your department or company has trouble in this arena, I recommend that you do a quick self-evaluation in the following four areas:

• Executive leadership - Do executives do everything in their power to enable your group to achieve your objective?
• Organizational structure - Does the organizational structure prevent your group from achieving your objective?
• Process paralysis - Do your existing processes prevent you from being able to achieve your objective?
• Bad goals - Are your goals achievable?

It is worth noting that bad goals are often cited as a reason for failure throughout industry. Fortunately, bad goals are simple to correct using techniques such as SMART goals. There are five guidelines for making a goal SMART:

• Specific - The goal should be exact regarding what the team hopes to accomplish.
• Measurable - When a goal is measurable, the team knows exactly when the goal has been achieved and what has been achieved.
• Agreed upon - Everyone involved in the process in question, especially all Six Sigma team members, must agree to the goal and agree that its successful completion is important. At some point, all team members and project stakeholders will be asked to contribute their time and resources to the project. Agreement commits everyone to achieving the same goal.
• Realistic - Whether a goal is realistic depends on the resources and needs of the organization. Make sure the goal is neither too ambitious nor too trivial. Make it just right.
• Time frame - Like all the elements of the project goal, the time frame should be realistic. The time frame should be achievable yet limited enough to make the goal valuable to the company.

By their well-defined nature, SMART goals help keep an organization or project team focused and dedicated to a common vision.

References:
Read the full study by Dr. David P. Norton: Making Strategy Execution A Sustainable Competitive Advantage
Read the article on the Be Excellent™ blog entitled "Making Strategy Execution A Sustainable Competitive Advantage"
Read the article on the Anticlue blog entitled "Six Sigma Creating SMART Project Goals"
Read an article on SMART goals from Raven's blog entitled "10 Tips for Setting SMART Goals / Objectives"

If you already have some degree of Project Management practices at your company, why would you hire a consultant to review those practices?  As a consultant, I get asked this question all the time.  Believe it or not, the answer is very simple and compelling.  Since it comes up frequently, I have decided to make a top 5 list on the blog.

1. A consultant provides objective feedback - Since consultants are not part of company politics they lend credibility to arguments impartially
2. A consultant provides a fresh set of eyes - Consultants will offer a different perspective on your ideas making them more comprehensive
3. A consultant can be a source of ideas - The very nature of consulting exposes people to many ideas and implementations that they can offer your business
4. A consultant can be your sounding board - Consultants can validate your ideas and give you the confidence to pursue them
5. A consultant can keep you accountable - Having the consultant review, probe, and strengthen your ideas helps keep you focused on meeting your company objectives

Have you had experiences with consultants that would add to this list?  If so, leave a comment.

This is an exciting time to be in the Project Management and IT industries, as both are rapidly maturing and adhering to common processes and best practices.  However, this is a daunting time to become a project manager or IT consultant.  Lots of frameworks, best practices, and methodologies are competing for your attention.  Some are good, some are bad, but most are "good in certain situations."  All of these new ideas remind me of a profound saying that I learned in college:

"In theory, theory and practice are the same.  In practice, they are not."

An example of this recently came to mind for me.  The IT Infrastructure Library (ITIL) framework is completely based around the idea of a Configuration Management Database (CMDB).  In theory, the CMDB combines information about all aspects of an information system, the business areas it supports, and service levels.  However, in practice no such database system exists.

If you are considering an ITIL implementation, please read the IT skeptic's blog.

On her Project Management blog, Raven's Brain, Raven discusses the possibilities of a Web 3.0 movement. Much like Raven, I am very skeptical of a new layer of intelligence on top of the shaky foundation that is Web 2.0. In fact, I remember when Web 2.0 was just starting as a movement and was itself promised to be "semantic web." Unfortunately, the reality is that this sort of "machine thinking" that Web 3.0 promises is still out of our reach today. Still, Web 2.0 delivered a much-needed infrastructure for shared information the likes of which the Internet could not hope to achieve without technologies such as Web Services, RSS, and AJAX. However, I believe that Web 2.0 still has much to accomplish before the groundwork for the next layer of intelligence is established throughout the Internet.

Web 2.0 still has a long way to go before we can even think of building on it as a stable platform. Among the current problems with Web 2.0 are:

• Some overestimate the power of automation via Web 2.0 technologies.
• Tagging is a very powerful technique but has so far not yielded much of its promise.
• Blogs constantly suffer from comment spam.
• Companies have yet to adopt public web services widely.
• Browsers are just starting to converge on a standard interpretation of web standards.
• User edited content such as wikis have yet to prove widely useful outside of the Wikipedia project

Despite these shortcomings, Web 2.0 has given us many useful tools and services. My favorite among these are:

• Wikipedia - http://www.wikipedia.org - Wiki encyclopedia
• YouTube - http://www.youtube.com - Video tagging and sharing site
• Live Spaces - http://spaces.live.com - A personal content sharing/blogging site
• Flickr - http://www.flickr.com - Photo tagging and sharing site
• Last.fm - http://www.last.fm - Music tagging and recommendation site
• MySpace, Facebook, etc. - Social networking sites

What are your thoughts on Web 2.0 and 3.0? Also, post up your favorite Web 2.0 sites in a comment.

When should you kill a project?

This is a topic that is rarely discussed in the industry because of the stigma of failure.  No one wants to look bad in front of his or her customer.  So they crash (add resources), fast track (do tasks in parallel), and generally throw good money after bad until a project completes or becomes impossible to complete.  This problem is typically magnified in companies where a project manager's reward is based on successful project completion.  However, as project managers it is our duty to monitor the health of a project and if the time comes where it makes sense to kill the project we should advise our customers honestly.  How do you know when the project really needs to be killed?  The answer is very simple.  There are three reasons to kill a project:

• The company strategic plan has changed and the project no longer aligns with business goals
• The cost of completing the project is higher than the expected return on investment
• The project is meant to exploit a window of opportunity in the market but it cannot make the schedule

If either of these conditions are true, kill the project.  I will go one step further and say this: kill the project as early as possible.  All good poker players know that it is better to fold early and only bet big when success is assured.  I have been on several projects where management did not kill troubled projects in a timely manner only to find that they spent more than planned and did not get the result they were hoping for in the end.

In my experience, the top two reasons that projects are not killed when it makes the most sense are:

• Fear of failure
• Project managers who value completed projects over fiscal responsibility

The first reason is a false belief that one looks good only when they are finishing projects.  This is the leading cause of reckless project management techniques to make the deadline no matter what.  However, from a business point of view, a project manager looks much better at review time when they demonstrate a fiscal responsibility to management.  Five killed projects for minimal losses and one successful one that makes a huge return is more beneficial to a client than pouring money into one troubled project that will ultimately not achieve its goals.

The second reason that projects are not killed timely is just plain irresponsible project management.  This happens when a project manager worries more about looking good in front of their boss than the interests of the company as a whole.  These project managers will sometimes whitewash information, hide facts, or generally make a project look healthier than it really is.  In the end, these projects inevitably fail to achieve their objectives.  Unfortunately, even if the project is ultimately unsuccessful these project managers succeed in convincing or deceiving management into investing more money than is probably prudent.

Do you have stories of projects that should have been killed but were not?  Leave a comment for the benefit of all the other project managers out there.

• The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it.
• Process improvement increases product and service quality as organizations apply it to achieve their business objectives.
• Process improvement objectives are aligned with business objectives.

• Executive dedication to process improvement
• Quantitative measurements/assessments
• Process review/modification based on feedback
• Stringent adherence to existing processes by everyone

This sounds hard, but it does not have to be.  Guides such as CMMI, provide a direct path from hero-based (level 1) operations to optimized, consistent, and managed (level 5) enterprises.  Additionally, Carnegie Mellon's Software Engineering Institute provides a formal CMMI appraisal service to formally validate an organization's maturity level.  However, this is not strictly necessary as the formal validation does not accomplish anything that an objective internal review would show.

If you have any experience with CMMI, SCAMPI reviews, or process maturity in general, please leave a comment.

Consultants often visit client sites to do our jobs.  We typically bring our laptops with us and connect to our client's network.  At this point in our relationship with the customer, I believe it is our responsibility to protect the customer's network from cyber attacks against our laptops.  The client is typically put into a very vulnerable position when our laptops connect to their network.  Imagine your client's reaction if they find out that your laptop spread a virus on their network or served as a gateway for hackers because you had wide-open wireless settings.  This would tarnish not only your reputation but also the reputation of your firm and the entire profession in general.  Having updated antivirus software and latest Windows patches is common sense; however, as consultants we have a professional obligation to go beyond the basics.  We must protect our laptops from exploits targeting wireless flaws that could render our client's data public.

Recommendations:

• Antivirus: avast! antivirus
• Firewall: Windows Vista Firewall or Jetico Personal Firewall
• Encryption: TruCrypt
• Secure Erase: Eraser
• Wireless: Turn this OFF physically unless needed at the client's site
• Screen: 3M Privacy Filter (protect sensitive data when working offsite)

If you have a story regarding an experience on this topic, please leave a comment on the blog.  I would love to hear them!

PS: There are ways to protect a network from potentially harmful computers.  To learn more, look into Cisco Network Admission Control (NAC) and Microsoft^® Network Access Protection (NAP).  Microsoft and Cisco have agreed to an architecture that combines both offerings as detailed in the NAC-NAP Whitepaper.

"Try this exercise. The next time someone (even you) makes a statement that sounds like a declaration of fact (an assertion that this is so, this is the way it is) ask, “How do you know?”

Then wait, and press if you need to, for an answer.

Don’t be surprised if you get one of two of the most common replies to that interrogatory: Common knowledge, or, my experience (or variations on these themes). Follow up these replies with a quest for more clarifying information.

“Common knowledge?”

“Yeah.”

“What do you mean?”

“You know.”

“I don’t want to make any assumptions here. Why don’t you tell me more about what you mean by that.”

If they say, “My experience tells me this is so,” you can reply with something such as, “You have direct experience with a situation just like this?”

“Yup.”

“Great. Tell me about that." -- Don Blohowiak

It is inevitable. At some point in time, either you or your employee will miss a deadline. Sometimes that deadline will affect customer deliverables and make you and your organization look bad in front of a client. This is the subject that caused Trizle to come up with a shortsighted initiative he calls "No Deadline Left Behind."  The premise behind this idea is to punish employees monetarily for missing deadlines. On the surface, this seems like a reasonable, maybe even sensible, policy. After all, an employee should be incentivized to meet contractual obligations. However, after some analysis this approach, though intuitive, is the wrong one.

It seems that Trizle means to punish employees for the failures of the project manager. Most deadlines are missed because of poor estimation, risk management, and progress tracking. Unless those areas of Trizle's process are fixed, he will just shift the blame and punishment of the problem on the poor employee who has little control over the actual deadline itself. The result of such a policy will be inflated timeliness (as employees seek to minimize their risk), higher costs (employees will charge more for some work to offset loses in other work), and no improvement in the ability of an employee to consistently meet a deadline. Furthermore, employees will reach a point where the risk of losing their income becomes so high that employment at Trizle's company will no longer be a viable option for them. As an example, Rob Garrett's response to this article demonstrates a typical employee's reaction to such a policy.

"No Deadline Left Unmanaged"

Instead of the "No Deadline Left Behind" as Trizle suggests, I have come up with a realistic strategy. The strategy starts in the planning phase of a project. Here, the typical pitfall is poor estimating. While it is common to use a team member's expertise to judge the effort required for a task, this path is dangerous and should be only used as a last resort. Instead, use techniques like parametric models, commercial databases, or weighted averages to get estimates that are more accurate.

Parametric models are mathematical formulas used to estimate the total duration of a task based on variables. For example, "it takes me 2 minutes to lay 1 tile, the tile is 1 foot by 1 foot, and the room is 100 sq. feet. Therefore, it should take me approximately 200 minutes to lay enough tiles to fill the room."

Note: Problems that are more complex require models that are more complex. Additionally, pay close attention to how well the model scales (it may take 2 minutes to lay 1 tile in a small room, but increasing the room size may not increase the total time in a direct proportion)

Weighted averages, such as used in the PERT technique, allow a manager to consider an optimistic estimate, the average estimate, and the pessimistic estimate to come up with a figure that is realistic.  The PERT formula for this is:

T_E = (O + 4M + P) ÷ 6

Where O is the optimistic estimate, M is the average estimate, P is the pessimistic estimate, and T_E is Expected Time. Performing a standard deviation analysis can show the manager how confident they can be in the estimate.

After these techniques are used to come up with estimates that are realistic, it is paramount to control the scope of the project to prevent missed deadlines due to scope creep.

The second phase of the strategy comes into play during risk management. Each employee should be positively encouraged and incentivized to report project risks to the PM (or risk management officer) immediately. The PM can then form a risk response plan to accept, mitigate, or transfer the risk of a missed deadline. Accepting a risk means realizing that a risk exists but doing nothing to prevent it. Mitigating the risk of a missed deadline could involve adding resources (crunching), re-negotiating the deadline, or doing tasks in parallel (fast tracking). Transferring the risk could involve obtaining an insurance policy (this moves the risk from you to your insurance provider).

Note: Punishing employees for missing deadlines is a form of transferring risk because they end up paying for your mistakes.

The third phase of the strategy is for the PM to be intricately involved in the monitoring and controlling activities during the execution phase of a project. A manager that does not track progress until deadlines are missed should shift their focus onto actively managing their people. Tools like EVM (Earned Value Management) are essential in effectively tracking project status. EVM allows the PM to "objectively track physical accomplishment of work [by] combining measurements of technical performance (i.e., accomplishment of planned work), schedule performance (i.e., behind/ahead of schedule), and cost performance (i.e., under/over budget) within a single integrated methodology."

In my opinion, these three improvements in the project management area will drive improved management of resources, risks, and schedule in a much more efficient manner than transferring risk to your own employees.

I have recently come across an article analyzing the Gartner Application Development Summit entitled What Gartner Is Telling Your Boss.  There are several reasons to pay attention to Gartner predictions.

Firstly, Gartner has built up a reputation as a reliable market analysis firm in our industry. No matter how we may feel about individual reports, it is an undeniable fact that the Gartner brand carries a lot of weight with executives in our industry. It is wise to keep on top of the latest opinions from the top major research firms when dealing with sophisticated customers such as ours.

Secondly, a client may ask us for an opinion about the matter when they learn of it. The worst possible mistake in the consulting industry is not knowing the latest frameworks, methodologies, and predictions before our customer. When our customers feel that we do not have our hand on the pulse of the market, they begin to question our usefulness to their organization. As IT Consultants we are responsible to our customers to appropriately recommend ideas from methodologies such as ITIL (Information Technology Infrastructure Library), ILM (Information Lifecycle Management) and others.

Thirdly, we must always analyze the communication approaches taken by others to reflect on our own presentation techniques. For example, this specific article mentions “agility.” However, Gartner has redefined the industry term “agility” by stating “the keys to unlocking the agility paradox are architecture; a focus on software process and engineering; and reuse — of everything.” This is of course in contrast to the “agile methodologies” which stress less process and up-front engineering than traditional development approaches. As an industry, we must be able to communicate our ideas to our customers consistently and reliably.

My analysis:

According to the article, Gartner is proposing that software developers should change their focus from creating applications to reusing code and creating middleware (or mash-ups). In my opinion, there is certainly a case to be made for code reuse. However, in my experience, code reuse has been a hard thing to actually achieve. Often times, business goals can be achieved better, faster, and cheaper by re-writing or re-engineering an entire application rather then investing in existing systems. It is often the case that business applications outlast the platforms (hardware and operating system) that they were originally developed for. In such cases, it is hard to add value to an existing product because the cost of integrating existing code into new products can be very high. Conversely, there is a greater trend of companies like Microsoft to create integration points into their own server software. These integration points may provide new applications with vital functionality at a fraction of the cost of developing the same code in-house. Unfortunately, I believe that Gartner has confused the message to a developer by providing them with the “how” but not the “why.” The message should not focus on code reuse or process improvement but on the end goals. Both developers and consultants are only here to do one thing. Enable our business clients to meet their goals while managing the costs associated with our activities.  Whether that means code reuse, improved processes, agile methodologies, or any other technique, our goal is always the same.

My advice:

• Always analyze your specific situation and apply the appropriate tools to improve it
• Never fix what is not broken
• Always approach a business problem by looking at people, process, and technology points of view. A business problem is rarely solvable without affecting all three.
• Managers must provide proper guidance (process and governance) to their employees without overburdening them
• Radical change (in terms of application development approaches and IT in general) rarely leads to positive results