Feasibility Study: Extracting Related Data from Paper Copies Via Automation

by Dr. Michael Covington, Director of Intelligent Analytics

The client had a large collection of legal documents, all relating to business transactions that were very similar and often interacted with each other.  The client needed a study of the feasibility of extracting structured information from the documents automatically and making a computer database.

The main challenges were:

- The documents used complex legal language, which existing natural  language processing tools often had trouble analyzing

- The documents were on paper, some poorly printed, and many with handwritten annotations

- The extracted information needed to be very accurate -- not a statistical sampling of the documents, but extraction of exact items.

The feasibility study addressed optical character recognition with human assistance (along with a longer-term plan to make this unnecessary by saving the documents as word processor files or textual PDFs), natural language parsing and information extraction, and "how to crawl before we walk" (that is, how to benefit from methods that are only partly successful).  A technical approach was recommended and the necessary implementation effort was successfully estimated.

Case Study: Increasing Project Fees to Make Customers Happier

by Krystina Francis, Director of Projects

The harder they worked, the less satisfied their clients were...

I worked with a company that offered marketing and web development services, and they would frequently get requests for rush work. The owners at the company were adding a laughably low rush fee to the project cost and wearing themselves out trying to meet demand. They would work 12+ hours a day and on the weekends, yet still miss deadlines. 

Full-time employees weren't being compensated for hours overages at the time, so the owners would step up to do the extra work. As a result of the owners' long hours focused primarily on production and not business management, the whole company was suffering. Their clients were increasingly dissatisfied with the timelines, and  the burn-out was starting to present itself in the quality of the work.

I took them through a very simple exercise to expose the issue, and it started with a very simple question, "How much is your time worth"? In order to determine what they were paying themselves for these extended hours, I required them to start tracking their time. (I will save the lecture about tracking where all of your time goes for another article, but everyone, regardless of their position within the company, should do it.)

After we broke out the rush fee against their after hours efforts, we determined they were getting paid something in the range of $5 an hour in overtime. To managers and owners of larger companies, this seems absurd, but small companies afraid of losing business by saying no or charging "too much", will often undervalue themselves and run into scheduling issues by overburdening their human resources.

Next we took a look at how they priced projects. Although they presented a flat project fee to clients, that was accompanied by a breakdown of how much time a component would take to build, and that was multiplied against their hourly fee and compiled to produce the project cost. Interestingly enough, we discovered through their time tracking that they were also underestimating the amount of time required to finish work. So in the process of fixing the rush fee, we also fixed their starting estimates.

From there, it was a simple thing to calculate a fair rush fee. If the project had to be done after standard working hours of 9am-5pm in order to move it up in the overall schedule, then their hourly rate was multiplied by time and half, increasing the base project cost to the client by 50%. This also allowed the employers to offer employees extra pay if they volunteered for these types of projects.

The results of these pricing changes were huge. It came to light that many of their clients didn't have to have the project rushed, they only asked for it because it was so cheap to do. The owners had been killing themselves to get work done for clients quickly, when 90% of the time the original timeline would have been fine. The clients that DID need work rushed, found the rush fee to be fair, and understood that the company had to pay employees extra to get them to stay late or subcontract the work which increased the project cost.

The owners would still regularly work long hours, but they had time to dedicate to the management of the company. Employees were happy to have an option for making more money but not being forced to work the extra hours. Clients were glad to still have a rush option, and the company didn't lose anyone as a result of the increased fees. It was win-win for everyone.

Case Study: What Wins the Deal Isn't Your Favorite Selling Point

by Mike Gomez, Director of Enterprise Growth

The real driving priority for a major contract decision may not be the most obvious one...

For years, a U.S. company pursuing a major military military aircraft sale in Europe had assumed the decision would be heavily weighted on performance and capabilities. (The competitors were the Russians MiG, UK Grippen , and the French Mirage.) This company spent considerable resources emphasizing these aspects and performing live demonstrations to impress the military.

During a state dinner, the Prime Minister of this country asked the U.S President why the U.S. firm kept emphasizing product performance when his biggest political issue was an 18% unemployment crisis. Puzzled by the question, the President directed this feedback be provided to the American CEO.

Mike Gomez was called away from his regional sales duties in the Middle East and sent to Europe to conduct a complete in-country sales strategy review. He used the Winning Customer Decisions© process with the entire campaign team (country expert consultants, U.S. Embassy personnel, multi-disciplined sale force, etc...) to thoroughly evaluate how this decision was to be made and the priorities that would guide it.

The process revealed the top 10 people who had a role in the decision were focused on trade, economic development, and geopolitics - not military capability. It became clear that jobs (to provide cover for the spending of national funds) and geo-political considerations (EU vs U.S) would dictate who won or lost this multi-billion dollar competition. 

Armed with this new understanding the U.S. company immediately launched a focused jobs and technology transfer campaign and eventually won the $3.6 billion (USD) competition.  In announcing the winner, the Prime Minister highlighted that their decision would bolster the relationship with the United States and, over the duration of the contract, bring thousands of high tech jobs to their nation.

Why Businesses Are Giving Up On Agile

by Krystina Francis, Director of Projects

The Agile Manifesto

Since that famed group of programmers crafted the Agile manifesto back in 2001, the methodologies that sprung from it gained rapid and widespread popularity. It was a backlash against the micromanagement of every line of code produced. Project size used to be based on how many lines it took to build the software!

No one could argue it was time for a change. The values from the manifesto were revolutionary (though likely evolved in part due to RAD approaches):

Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan

We now have years of project data to draw on along with feedback from managers and companies, and unfortunately what we see across the board is a high failure rate and sub-par results from projects that use Agile methodologies.

Agile Principles in Practice

When someone says they develop using Agile, what they are really referring to is one of the management methods based on its principles, such as Scrum. They all use some form of an Iterative approach, meaning that development happens during repetitive cycles where work from the previous cycle is built upon and expanded.

So what happened? Let's examine each of the Agile principles and what occurs when they are used in reality

1. Customer satisfaction by rapid delivery of useful software

Customer satisfaction is not derived from software simply working or even being put in their hands quickly.  Satisfaction stems from their problem being solved successfully: a solution that makes their life easier.

Typically, a Project Manager would be gathering voice of the customer through various means early in the project to fully understand the business case, but many Agile methodologies ditch a PM in favor of other communicator roles, like the Product Owner, and development begins with a loose set of goals.

The Product Owner is focusing on the Stakeholders at each iteration's review period. That will almost never include the actual end user, because imagine how long it would take to coordinate a focus group at the end of every iteration!

Change is therefore driven from within the organization to a large extent, which is probably why they had to come up with #2.

2. Welcome changing requirements, even late in development

Probably because the customer finally had a chance to look at it...

But the fact is the more code that exists, the more complicated changes become. Changing one feature in the software will have a domino effect on many other aspects. Anyone involved in software development or testing will recognize that late changes and re-factoring of code takes an enormous amount of time at the end as compared to changes made early on in development. The number of bugs found will multiply with the complexity of the software.

I know why this principle exists- no one wants to see a major flaw in the software right at the end and not be able to fix it because typical project constraints are too tight. Unfortunately, the other extreme means you are developing without a clear plan and will theoretically never finish your project well enough to actually use it.

And this happens far too often. Agile projects often fail because they can't reach their objectives before resources give out. Iterations towards the end of development produce less new work because more time is spent debugging massive amounts of code as a result of new changes.

3. Working software is delivered frequently (weeks rather than months)

Early on, you feel like great progress is being made because you have something tangible right away. It is a lot easier to manage Stakeholders if you have something new to show them in each conversation, as opposed to just giving them an estimate on how much programming has been completed during a typical project execution phase.

Because you can actually see the work, there is more clarity around what hasn't been done yet.

However, the same pitfall occurs here as did with #1. Focusing simply on working software, and not whether it is meeting the business case is an easy trap to fall into.

4. Close, daily cooperation between business people and developers

This is the utopia we always dreamed of... but it never happens. Most business people do not have time daily to devote to the project. Even more incomprehensible is that most of them don't want to be involved daily. This is one of those bullet points that has CYA written all over it.

Ambiguous Business Person: "Why didn't this online form have these 23 if/then scenarios built in?"

Smug Programmer: "You were invited to EVERY daily meeting. This is on you."

At the other end of this spectrum is the micro-manager that sits next to the developer watching every change and giving feedback. Occasionally this works well, but if not managed properly the behavior can be detrimental to overall productivity.

5. Projects are built around motivated individuals, who should be trusted

Excellent in theory, harder in practice. Sometimes you just have to work with who you have, and sometimes that means you end up with a stinker on the team, which will effect morale, which will effect productivity, and on it goes... Don't underestimate the need for a strong project leader. 

6. Face-to-face conversation is the best form of communication (co-location)

True. 55% of communication is non-verbal! Rarely are teams located in one place anymore, though. With many companies opting to partially outsource, you are trying to coordinate teams across time zones, potentially cultures, and the actual distance. Unless you are using video conferencing at every meeting, a lot is getting lost.

By not keeping track of the expectations being set at each meeting, there will be miscommunication among the team members. Ever have one of those conversations? "Wait, I thought you were doing that task? We just talked about it yesterday." "No, I said I couldn't do it without full read/write access to the database so you said you would."

And because daily meetings are surprisingly hard to coordinate when the team isn't in the same location, that sort of issue may take a lot longer than a day to uncover.

7. Working software is the principal measure of progress

When it works and serves to meet a need, this can be an excellent approach.

8. Sustainable development, able to maintain a constant pace

As discussed in #2, a constant pace is not possible as the code base grows and more bugs are introduced with new changes. We know that adding people late to a project can actually cause further delays ("The Mythical Man-Month"). You could offset some of this with really good planning up front, but these methodologies shy away from detailed planning unless it is specific to the iteration at hand.

9. Continuous attention to technical excellence and good design

This is an aspiration that should be present in every project no matter the methodology. It does require a veteran programmer to conduct peer code reviews and UX specialists to weigh in as development happens. A/B testing with focus groups can refine design even further.

Without a strong project leader too coordinate these activities, they will often fall by the wayside. Quality control processes in more traditional project management exist for a reason.

10. Simplicity—the art of maximizing the amount of work not done—is essential

Now we herald Lean development practices. Focusing on the simplest solution to the problems outlined in the business case is no longer an option but a necessity in order to be successful. The problem here is knowing what doesn't need to be done rests heavily on knowing what does have to be done. Planning, people.

11. Self-organizing teams

Three words: college team projects. It doesn't work any better in the real world either.

12. Regular adaptation to changing circumstances

The larger the organization, the slower it will be to adapt to change. Though largely unintentional, the resistance to change becomes an expectation among employees and gets incorporated into the culture. Smaller companies have the advantage here, but in small teams having just one member be resistant to change can cause the same issues and breed negativity.
 

Agile Became The Ultimate Excuse for poor work

Aside from the challenges various methodologies have had in successfully applying Agile principles, perhaps one of the biggest reasons that Agile is beginning to lose its shine has to do with how loosely it is used to justify bad development behaviors. I have literally heard every one of these statements and so have many other business owners. And the end result of all of them is disorganization and poor customer satisfaction.

"We don't document our software or version releases because we are Agile."

"We don't do impact studies. We will just go in and change it again if it causes an issue."

"We don't do scheduled roll-outs, because we develop on the fly."

"The customers will use what we tell them to."

"We don't notify customers of upcoming changes. We don't know when we will finish them."

And many, many other statements that make me cringe. Thankfully hybrid methodologies are gaining popularity, striking a good balance between too much management and too little.