Category Archive for: ‘ROI’

Transforming employees into shareholders may not be a good idea 1

Logic would tell us that offering shares of your company to your employees (assuming they are offered at a good price) should clearly boost performance and allow the organization to achieve exceptional results. After all, wouldn’t most people work harder, reduce inefficiencies, increase their performance and chase sale leads once they become shareholders?

Turns out logic does not necessarily prevail in this situation and results may not be extra-ordinary.

Let me share with you our not-so-successful experience.

Our experience

I’ve already stated that Pyxis is an experimental laboratory and like many people, we understand that money by itself is not a good motivator. We also believe that sharing the wealth with the people who contribute toward achieving the business results is not only a good idea, but it is for us a morale obligation.

So at the end of 2007, the founder and then CEO agreed to sell 25% of his shares to the employees with the intend to increase performance and share the resulting wealth – in addition to using it as an employee retention strategy. At the time, almost 100% of the employees created a cooperative to own shares of their company. It is important to specify that our province offers important tax credits to employee-owned cooperative – which was an important driver in creating a cooperative.

The conclusion after more than 3 years of having employee-shareholders is that the intend and the objectives were right but the way to achieve them weren’t done right. Why is that? I asked myself.

Below are my conclusions but before we get into those, I believe it is important to understand the distinction between being an employee and being a shareholder.

What is an Employee?

An employee contributes labor and expertise to an endeavour. Employees perform the discrete activity of economic production. Of the three factors of production, employees usually provide the labor.

Specifically, an employee is any person hired by an employer to do a specific “job”. In most modern economies, the term employee refers to a specific defined relationship between an individual and a corporation, which differs from those of customer, or client. Wikipedia

What is a Shareholder?

A shareholder or stockholder is an individual or institution (including a corporation) that legally owns one or more shares of stock in a public or private corporation. Shareholders own the stock, but not the corporation itself. Wikipedia

Clearly, there is a distinction between the role and contribution of an employee versus that of a shareholder. For one thing, transforming employees (with their behaviors and attitudes) into full-fledged active shareholders doesn’t happen over-night. To be honest, it still didn’t happen after over 3 years for almost 1/3 of the employees. Did we hire people who were not driven by results? Well, maybe for a couple of people but certainly not over 30% of the people. So why is it that results didn’t go through the roof?

After much analysis of the situation and heated debates, I believe there are a few reasons why transforming employees into shareholders didn’t give outstanding results:

Creating a cooperative has a non-capitalistic connotation: People who initiated the process of selling shares to the employees also wanted to implement a coop as a way to distribute wealth. Unless our implementation of a coop is very different than elsewhere in the world, many people understood a coop to be a non-profit driven initiative and as such, acted accordingly. Having a coop own 25% of the shares led to non-capitalistic behaviors and consequently slowed down growth and profitability.
Becoming an active shareholder isn’t the norm: Unless you have owned and operated a business in the past, the notion of becoming an active shareholder isn’t easily understood by most people. Many people – still to this day – ask themselves what it means to be a shareholder and how they should act differently. Transforming employees into shareholders is an educational process and unless you invest in training people what it means, the transformation will not give great results.
Lacking entry criteria brings performance downwards: Since everyone got access to shares without exception, there was no motivation to increase performance – why work harder than the next guy when the results are shared equally. On the other hand, when past performance is used to determine who gets the privilege to own shares, individual and collective performance is increased and as a consequence, the overall performance of the organization goes North.

Consequently, attempting to transform employees into shareholders overnight was a mistake in our case. If we had to do it again, I would still give employees the opportunity to own shares but it would be done according a different approach:

Owning shares is a privilege and would be based on past performance;
Allowing employees to own shares would be done in small increments, and annually (let’s say x% per year);
Potential shareholders would need to demonstrate their understanding of what it means to be an active shareholder and would need to agree to certain protocols;
The percentage of available shares would be results-based – the better the organizational results, the more shares would become available.

Based on this experience, I would gladly grant shares to employees who clearly understood the meaning and responsibilities of being an active shareholder and who have demonstrated (and are still demonstrating) outstanding performance. Otherwise, there is no wealth to share…

Posted on: 04-25-2011
Posted in: Leadership, Management, People Management, ROI

The world would be a better place without accountants 2

It dawned on me recently that organizations are lead and managed by accountants. Accountants come in many shapes and forms and not every accountant wears brown socks.

I suspect you will disagree with my statement arguing that your CEO isn’t a former accountant or that your CTO didn’t even take a single accounting class in his life and I would agree with you. Not all accountants carry a pocket size calculator.

I personally don’t have many complaints about accounting itself, after all there is value in knowing how much money enters your coffers and how much you had to spend to generate the associated revenue. That makes perfect sense to me. Where I have a problem is when common sense leaves the building to make place for accountant-based logic and the need to book everything against the right account and the use of money within certain time intervals.

Confused? Let me explain.

Let’s take project management [Ah, now you are starting to see a link between accountants and Agile projects]. In many of the organizations I had the pleasure to work with, compliance to project plans was more important than delivering real value to customers. Nobody asked if it made sense to add new features or change the sequence of activities in an attempt to deliver business value to customers faster. People are concerned with compliance to the plan. And where does this need for compliance come from you ask? Accountants.

Before the debit-credit masters come running after me with their red pen, I will confess I used to be one of them (sorry!). I understand the mindset, their perspective of the world and most of all, the need to put things in neatly defined categories – some can be amortized while others can’t – but I digress.

The project timelines are derived from the accounting cycles – the money is allocated for a certain budgeting period instead of true market needs. The phasing and allocation of the resources is driven by the departmental allocated budgets. The profile of the resources assigned to a project is driven by who has the money as opposed to who has the skill set.

Does any of this make sense in a context of business excellence? That’s one of the reasons why I like Scrum with its focus on delivering the highest business value sooner. Scrum isn’t perfect, I know but it forces people to make decision based on business value, not accounting rules.

Scrum is also great a giving visibility the what is really going on within a project as opposed to estimated project completion for cost computation. In heuristic tasks such as software development is it really critical to know that task ABC costed $357? Chances are, you are unlikely to do anything useful with that information. Why wouldn’t you rather determine the cost of an iteration (or a sprint) so you can compare it to the business value delivered. As I stated earlier, there is value in accounting but when everybody starts to behave like an accountant, it is a sure sign that common sense is gone and that the organization is ripe for an Agile makeover.

Posted on: 08-17-2010
Posted in: Agile, Processes and Tools, ROI, Scrum

Does your organization support prostitution? 6

Does your organization’s compensation model and your personal attitude support prostitution?
[Note: The definition of prostitution is provided at the end of the blog post. In the context of this post, I am referring to the second and less often used definition.]

The Scenario

As the head of a large Information Technology department, you walk by Michael’s desk one afternoon and to your surprise, you notice that your system administrator is frantically switching from Google to Chat to a discussion Forum. You recall similar observations a few weeks ago so you quickly wonder if, at $80K per year, you are getting your money’s worth for a system administrotor who always seems to browse the internet. To make matters worst, you don’t even remember when was the last time your company ran into serious systems issues. Do you need Michael on your team? Maybe he is a good candidate for the headcount reduction you have been imposed by Finance.

A few days later, on your way out of the office around 7:15 pm you hear key strokes and notice that Kim is still working. You remember approving Kim’s over time report last month and start to realize that the increase in ERP support calls might be starting to impact Kim’s work-life balance. Remembering your conclusion about Michael, you wonder if you shouldn’t close the system administrator position and add resources to Kim’s team. At $55K per year, you would still be able to cut your budget spending. Pleased with your conclusion, you briskly walk to your car hoping for a nice family dinner.

A New Concept

Here’s a new concept. For people working in most traditional organizations, this will sound like a really weird concept but what if employees decided their own working hours? I’m not talking about the flex time concept where people decide what time they wish to start and end their work day but actually decided how many hours and which hours they worked?

Typically, the traditional work week varies by company and by country. A standard work week in Canada is somewhere between 35 and 40 hours per week. Some would argue they work many more hours per week but that’s not where I want to take this discussion.

Imagine for a moment you stopped controlling the hours worked and focused instead on the results. Granted, this is a much more complex endeavor but in my opinion much more suited to year 2010.

The Old Paradigm

At the beginning of the industrial age, many employees were paid “by the piece”. For every bolt fastened, shirt sowed, or widget delivered they received a small amount of money. Eventually, companies realized that it would be more predictable and easier to manage if people were paid by the hour. Needless to say, the model has somewhat evolved and employees are currently paid by the hour, by the day, by the week, or by the year but the model pretty much remains the same.

The New Paradigm

The new model I’m proposing is to offer a fixed salary (or a risk salary), without any expectations of number of hours worked. Instead of expecting people to work 40 hours per week, people would be expected to deliver value or results. As I mentioned, it is certainly more difficult to set up the type of results expected but on the other hand, isn’t this the basis of commerce – I pay you $x for this good or service without any consideration about how many hours were required to produce it. The production piece is the responsability of the seller, not the buyer.

Back To The Scenario

Pleased with the previous day’s conclusion, you call into your office Michael and Kim’s direct supervisor to share your thoughts. Michael’s boss explains that since hiring him 2 years ago, systems outage have dropped 92% as Michael is consistently looking for ways to improve systems availability. He heavily praised Michael for creative and pragmatic solutions and despite the fact the Michael rarely has to do overtime, he would recommend him for a promotion.

Slightly shocked, you turn to Kim’s boss and ask for comments on her employee. With a grin on her face, Kim’s manager tries to hold back her answer as it certainly wouldn’t make you look good. She explains that Kim clearly lacks analytical abilities which is why she has to spend more time than all her colleagues solving similar issues. In addition, Kim is a poor team player. She likes to think of herself as a super-hero and she prefers trying to handle problems without the help of her team mates which often leads to repeated issues as the root problems are rarely solved properly the first time around. Despite many attempts at helping Kim with her shortcomings, she doesn’t feel the need to improve since she is often praised by the head of the department for putting in long hours…

(Silence in the room)

Embarrassed and apologetic toward both managers, you realize your attitude toward the number of work hours per week may have had the opposite effect that you were originally looking for. You genuinely thank your employees for their valuable feedback and wonder if you shouldn’t aim to leave early today…

pros·ti·tu·tion (prst-tshn, -ty-) - NOUN:

The act or practice of engaging in sex acts for hire.
The act or an instance of offering or devoting one’s talent to an unworthy use or cause.

Posted on: 01-3-2010
Posted in: Environment, Leadership, Management, Organizational Structure, People Management, Perception, ROI

Would you have the courage to kill your "puppy"? 1

Few people have the courage to kill their "puppy"

Before you call animal protection agencies, I need to warn you upfront that this blog post is not about taking the life of man’s best friend. This post is about making difficult decisions – very difficult decisions when it comes to ending your own initiatives. For the record, I love animals but I found the analogy so powerful that I decided to use it to support my perspective [thanks to earlier blog post. I already highlighted 2 very different methods of launching new initiatives and in this post, I want to write about a leader’s ability to kill an initiative before it reaches full potential. No sane person launches an initiative or a project with the objective of not being successful.

Too many organizations lack the ability to innovate so when an organization has the amazing ability to generate new ideas, it is a wonderful thing. In such organizations, employees are motivated and the company makes sure it will continue to grow by bringing innovations to the market. Such organizations typically have a healthy pipeline of ideas that help them re-invent themselves. Some large organizations even have the goal to generate more than 30% of their revenues from products created in the last 24 months. That’s an aggressive but worthwhile strategy.

The challenge I have seen is with smaller organizations where the initiator of the idea is also typically its leader. In such circumstances, the leader no longer has the ability to take a step back and see things as they are – not as he wants them to be. After investing money and personal energy and imagining such high potential, making the right decision about pursuing the project (or not) when the results aren’t there is nearly impossible. The emotional ties to the project are so strong, it requires a lot of courage to make the decision to kill the project.

What do you do when the initiative doesn’t deliver on its expectation? Do you keep moving forward or do you put an end to the project? When do you know when enough is enough? How do you know you didn’t kill the idea too soon?

Unfortunately, there are no easy answers to these questions except it depends… It is obvious that the decision to end an initiative is much easier to make when you are not emotionally associated with the initiative. Not having taken part of the initiative makes it easier to use clear-cut criteria and apply them. If the project didn’t generate the expected revenue or doesn’t meet which ever other criteria used to evaluate it, it is much easier to decide to cancel it – to make a rational decision instead of an emotional one.

As with every thing in life, no one can ever be certain that the decision was the right one but I firmly believe that making no decision (or maintaining the status quo) is worst than making a decision. Isn’t insanity the behavior of repeating the same actions and expecting a different outcome?

As for your initiatives, stop seeing them as puppies. Take a step back and if you must kill your project, see the experience as an opportunity to develop new skills that you will need further down the line. As Agile people keep saying “Inspect and Adapt” which is a clever way of saying “Learn from your mistakes, and move on”. Very few large success happened on the first attempt. See your failed initiatives as a pre requisite for your next success.

I’ll tell you about some of my “puppies” in an upcoming post…

Posted on: 12-1-2009
Posted in: Leadership, Learning, ROI

We have a huge budget and too much time to complete our business intelligence (BI) project 0

If you agree with the title of this post then you don’t need to read further, either your business intelligence (BI) project will be amongst the very few (less than 40%) that will not end in abandonment / failure or you do not have to worry that your project will drain your huge budget before slowly and gradually failing.

For everyone else, this article that presents the benefits of using an Agile approach to software development. This post is a follow up to my previous article called Nobody is interested in Agile where I wondered why so few articles explained the actual benefits (the WHY) behind Agile.

Why should organizations use an Agile approach for their Business (BI) Intelligence projects?

In clear business terms, using an Agile approach for the development of your BI solution will greatly increase your return on investment (ROI). Before reading further, you need to keep in mind that Agile will not address all of your software development issues but by empowering the people who are directly and indirectly part of your project team and by taking a pragmatic and realistic approach to the software development process, the implementation of Agile principles within your organization will address the most critical problems typically encountered by a software development project.

The following diagram summarizes the 7 key benefits of implementing an Agile approach for your business intelligence project. Each of the benefit is explained further below.

increased return on investment by using an agile approach

The intent of this post is not to describe the Agile principles nor to explain which practice should be applied in a specific context but to describe in clear business terms the benefits derived from these practices.

Increasing Productivity

The throughput of your development team will greatly increase once you implement agile methods. The associated benefits:

Streamlined and improved face-to-face communications;
Continuous performance improvement by retrospecting at the end of each short iteration;
Progress is not measure by looking at compliance to a project plan but by evaluating by the quality of the output;
Project management is shared by everyone on the team instead as the team self-manages and becomes fully accountable for the results and reporting mechanisms;
Use of proven and innovative software engineering practices greatly improves quality;
Increased ability to estimate efforts and time lines;
Team productivity can be assessed and monitored over time which provides a predictable rhythm.

Meeting Time Commitments

Project time lines are typically very critical and as such implementing an Agile approach help meet time commitments.

Reduce the overall scope into small manageable chunks and maintain focus on short term delivery instead of the final end date;
Make the team’s progress visible to everyone with the use of defined reporting (burn down chart);
Team has to demo working product at the end of each iteration;
Estimating and scheduling is a collaborative process shared between the customer and the project team;
Frequent delivery of software reduces the overhead of moving the application into production;
End users are involved in defining the time lines instead of leaving the activity to the development team.

Increasing Quality

Quality is never negotiable so implementing Agile is beneficial to the project team.

Team has to demo working product at the end of each iteration;
Early detection and fixing of faulty components;
Testing is not only done at the end of the project when the cost of fixing issues is much greater;
Tests may be written before the development cycle begins and must be continuously be run throughout the duration of the project instead of waiting until the end.

Delivering on Requirements

Many projects are delivered without meeting the expectations of the customer. Using an Agile approach helps the team deliver on the requirements.

Customer is part of the project team, defines the priorities and assesses the end results;
Obtain continuous feedback throughout the development cycle and not only at the end;
Team will deliver on the original requirements but if there are requirement changes, the team will provide opportunities for feedback and adapt to meet the changing requirements;
Analysis and design is done at the beginning of each iteration and not only at the beginning of the project;
Software should meet the current needs, not the needs that were defined months before.

Delivering Business Value

As opposed to emphasizing tools and processes, Agile focuses on delivering value to the organization.

Teams work on value added tasks (as opposed to paper work and attending meetings);
Teams delivers the highest value features first and avoid building components that will never be used by the customer;
Focus on results (as opposed to process oriented or project plan driven);
Time boxed to ensure compliance to defined time lines;
Costs and benefits can be associated directly with the pieces of software being delivered, if the estimated cost for a component is greater than the anticipated value the component may not be developed;
Reduces or eliminates non-critical activities;
Raising issues and impediments early in the process reduces the cost of fixing them later on.

Improving Knowledge Sharing

As Agile relies on the concept of the team as opposed to the individual, knowledge sharing is a direct benefit.

Prevents the fact that a single individual becomes the bottleneck for the project by emphasizing sharing of information and tasks amongst the team members.

Increasing Employee Satisfaction

Although not frequently mentioned, employee satisfaction is an important benefit of implementing Agile.

Relationship between the project team and the customer are improved by developing trust and sharing knowledge throughout the duration of the project;
Team self-organization and autonomy greatly improve team members’ morale;
By inspecting and adapting their work processes, the team members grow their skills and motivation;
Given the opportunity to play various roles on the development team, individuals increase their satisfaction by developing new skills.

As I mentioned in my previous post, there were very few articles that explained the benefits (the WHY) of implementing an Agile approach for software development project. Hopefully, this post will help you promote agility within your organization.

Posted on: 04-27-2009
Posted in: Agile Business Intelligence, ROI

Improving ROI and Success Rate of your Business Intelligence Project 0

It has been a while since I posted on my blog. The reason is that in addtion to taking some time off for a wonderful family vacation, I was finalizing the white paper I had started a few weeks ago. You can find the document call Improving ROI and Success Rate of your Business Intelligence Project on Pyxis’ web site.

Share your thoughts.

Posted on: 04-4-2009
Posted in: Agile Business Intelligence, ROI

Explaining the business value of incremental development 3

Here is the second of two posts on iterative and incremental software development. My previous post focused on explaining the business value of iterative development while the objective of this one is to explain the value of incremental development.

Incremental Software Development Applied to Business Intelligence

Starting with the decision of using an incremental development approach as opposed to a sequential approach for the development of a BI solution results in 3 immediate outcomes:

Reduces overhead: Once the development team determines it will be using an incremental approach, this decision allows it to focus on small tasks and build on them. As such, it is no longer required to plan upfront for every component to be built which would be the recommended approach if the team only had one attempt at building the right software. By developing the application in increments, the team can focus its efforts on the tasks at hand within the known context and not worry so much about figuring out all possibilities at the beginning of the project.
Allows continuous integration: Building incrementally is a good step in the right direction but if the incremental components are not continuously integrated to make a whole, the development team wouldn’t achieve all the expected benefits. As such, the team would be building many items that could fit into a bigger whole without making sure all the pieces actually fit together. By continuously integrating the components, the development team ensures that throughout the development cycle, an integrated “application” can be tested and possibly demonstrated to the business community.
Allows test-driven development: Using TDD as a development practice forces the development team to prepare their test cases before starting their development. In addition, every time news conditions to be tested need to be integrated, the tests are documented before the code is written and then executed once the components become available.

In turn, these 3 elements lead to 3 clear outcomes:

Improved software quality: Preparing test cases before starting the development, enhancing the test cases with new possibilities as they occur, and continuously executing the test cases on the incremental components as they continuously get integrated within the global build improve the overall quality of the software being developed.
Reduced overall cost of the project: By spending less time on overhead activities and delivering better quality software, the overall cost of the development project is greatly decreased.
Increased ROI of the project: Combining the impact of the various outcomes increases the overall ROI of the project.

Posted on: 03-10-2009
Posted in: ROI

Want to get results sooner? 0

In an attempt to demonstrate that an iterative and incremental development process produces results faster, I came up with a quick comparison. Although simplified, I am using some fairly straight forward assumptions to demonstrate my point.

The following graph compares the cumulative costs-benefits of each approach used for a Business Intelligence (BI) project. BI projects notoriously require a lot of time up front to plan, architect, and design the solution. Once these initial steps are completed, up to 70% of the development team is spent on the development of the ETL. All these efforts are usually required prior to delivering key performance indicators (KPIs) to the business users.

As can be seen, both approaches require an initial investment in the development of the solution but after the third iteration (month 3), some value is already being delivered to the business user when using an iterative and incremental approach.

Using a project management view, the waterfall approach typically requires that activities get completed before moving to the next one. As such, the development team needs to progress through each step before the BI application can be deployed in production and the business users gets to see his first KPIs. This is in the best case scenario where the initial requirements were accurate and the business context didn’t change for the duration of the project.

By comparison, short iterations (typically between 20 and 30 business days) that focus on end-to-end solutions quickly provide results to business users.

Some planning needs to take place prior to launching an iterative and incremental project (which will be discussed in another post) but the obvious value is in delivering results sooner.

Do you know a business user who wouldn’t be interested in such an approach?

Posted on: 02-10-2009
Posted in: ROI