Show them the numbers – it’s results that matter
On a recent project one of our customers had some questions about the project’s progress. The project was a mid-size systems integration between Oracle Financials and Onyx CRM for a Fortune 500 company.
As with many large companies, there were several business units and people with interest in the project, and also as with many large companies, people had several other projects to deal with and were not attending the daily standups or weekly progress meetings.
I began to hear that there were some concerns about the project progress from some of the management team and a concern that we were spending too much time writing tests instead of code.
This came as a big surprise to me: from the perspective of the team working on the project on a daily basis (both customer and ext.IT), we were sailing along with no problems. We were providing the usual artifacts such as status reports which showed how we were tracking against estimated hours and when our code complete date would be, and all of this was tracking well against our original estimates, so to hear that people were unhappy was a big shock.
I called a meeting with all of the stakeholders and as soon as I invited all of the stakeholders I realized two things:
- This meeting would be the first time in the whole project that all of the stakeholders had been in a room together.
- While we had discussed our approach during the initial engagement, we hadn’t held a project kickoff with all of the stakeholders to discuss our approach to building software.
Both of these items were my fault, but here I was, several months into the project with an unhappy customer, so I thought I would address it in this meeting.
I put together a short presentation which discussed our approach to building software, including brief descriptions of how we perform iterations, test driven development, automated acceptance testing, retrospectives and other benefits to the way we build software, and why we considered our approach to be best practice.
Almost as an afterthought, I ended the presentation with a couple of slides showing our project status. This was an afterthought because everyone at the meeting was a recipient of the weekly status report containing the same information. I created one slide comparing our original project estimates (before we had detailed requirements) to our detailed estimates (once requirements were fleshed out) and to our actual hours so far on the completed features, and another slide showing our defect count and comparing it to another of the customer’s internal projects that they had build without the benefit of automated tests.
Once the meeting started, it was clear that I didn’t need any of the slides about our approach. We spent a few minutes discussing the original estimates against the actual time taken for completed features: everyone was happy with the job we had done in estimating against the original high-level requirements. We also discussed how we were tracking on the hours left: again, everyone was satisfied with the results. Finally, we spent five minutes comparing the low defect count on our project (with a high level of test automation), compared to some of the customer’s other projects (without unit tests), and everyone was satisfied with this too.
There wasn’t a single question about our approach, and ultimately no-one in the higher echelons of the customer’s business cared about the minutiae of our approach, nor were they interested in why we thought our approach was best practice.
They simply wanted to see the results of our approach.
In retrospect, this might seem obvious, but the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.
To conclude: After this meeting, the project was delivered successfully without any more concerns from the customer. We were one of several projects integrating with Oracle and we were the only project to deliver on time and under budget, with a very happy customer!
How do I manage changes to the Onyx Employee Portal UCW?
With Onyx CRM version 6.0 and Consona CCM 7.0, you have a great feature called UCW (UI Configuration Workbench). There are several benefits to using the UCW. The Onyx Employee Portal 6.0 Technical Guide lists the main ones as:
Ease of configuration: UCW provides WYSIWYG configuration of many areas in OEP, enabling you to configure, compile, and test your configurations, including changes to user navigation and form presentation and behavior.
Custom OEP pages for different teams: Using UCW and OEP Profiles, you can configure the same OEP page differently for different teams in your organization, enabling profile-based user navigation and page presentation and behavior. You can apply your UCW configurations to one or more custom UIs (accessed via the related OEP profiles) or to all custom UIs at once (using the baseline UI accessed with the Global profile).
Upgradeability: When you configure OEP using UCW, you ensure that your UI configurations will be upgraded to the next version of OEP without requiring you to rewrite or re-implement your modifications. Customizations that are implemented outside of UCW, however, are not automatically applied when OEP is upgraded.
However, while the technical documentation has some best practices and tips and tricks, what isn’t well-documented is how to work with the UCW so that you can more effectively manage your UI changes. This post will show you how to split your UI changes into layers.
Following the approach I am about to describe has the following benefits:
- Several developers can simultaneously work on different UI features at the same time (in different developer environments) without causing any dependency issues or needing to “check out” or lock files.
- Changes to one area of the UI can be deployed without worrying about changes in other areas.
- Splitting the changes into layers means that you can “throw away” or remove whole areas of customizations without needing to manually edit the global delta xml files or delete your changes through the UI.
How does this work?
It’s very simple. When you make changes in the Onyx / Consona UI, the UCW framework is tracking those changes and adding all of your actions to one file called global_delta.xml. This file is found here:
EmployeePortal\ucf\data\layers\active
By default, all of your changes live in this file, whether they are changes to the company edit screen, the incident edit page, or the powerpage. This is undesirable and means that all of your customizations have dependencies and only one person can work on UCW at a time, even if you have several development environments, so it’s best to break up the work into custom layers.
Before your start, please add your Onyx UI files to source control! There are many choices and a lot of them are free. We use Assembla’s hosted Subversion repositories.
To add a custom layer, follow these steps:
- Navigate to EmployeePortal\custom\ucf\data\layers.
- Create an empty folder with your layer name. For example, if you want to add a layer for the company powerpage, name this folder companypowerpage.
- Navigate to EmployeePortal\ucf\data\configuration.
- Add the path to your layer to the layers.xml file. Set the sequence number so that this comes before the active layer and after the onyxvalidation layer. Adjust the sequence number of the following layers. In the screenshot below, we have added two custom layers: one for the company powerpage and one for the company edit screen.
The first time you edit your new layer:
- Navigate to EmployeePortal\ucf\data\layers\active – ensure that this is empty!
- Make your changes to the layer you are configuring.
- Move (not copy) the global_delta.xml file that has been generated in the ucf\data\layers\active folder back to the folder you created within custom\ucf\data\layers
Each subsequent time you edit your new layer:
- Navigate to EmployeePortal\ucf\data\layers\active – ensure that this is empty!
- Move (not copy) the global_delta.xml file within custom\ucf\data\layers over to the ucf\data\layers\active folder
- Make your changes to the layer you are configuring.
- Move (not copy) the global_delta.xml file that has been modified in the ucf\data\layers\active folder back to the folder you created within custom\ucf\data\layers
That’s it! Now you can effectively separate all of your Onyx UI changes into a more manageable structure.
Pragmatism in Business & Technology Strategy
Wiktionary defines pragmatic as:
pragmatic – Practical, concerned with making decisions and actions that are useful in practice, not just theory.
As a technology consulting organization we frequently get asked to assist people in defining or refining their business and technology strategy, or to explain why we’re an organization that people should work with.
My normal response when giving advice or answering this question is pretty simple: we focus on results – achieving a positive outcome for the business (in our case our customer’s business). I then go on to explain a little more of my thinking…
It’s rare to find a problem that has only a single possible solution – in most cases there are are a number, with some being better or worse, easier or harder, cheaper or more costly etc. How do we weigh up the options and help people pick the right approach? One word comes to mind: pragmatic.
Here are some ideas that we consider when helping our customers make pragmatic strategy choices.
Look Back as well as Forward!
Reality dictates that unless your business is a startup any strategy must co-exist with products, processes, systems and technology that are already in place. While we shouldn’t be bound by the past and present if there’s a good reason to move in a different direction, we should at least consider the implications for a business in moving to a new strategy.
Of course, this is also a good way to avoid making the mistakes of the past all over again.
Plan for Change
I’ve often heard people say that change is the only constant! Organizations grow, shrink, get acquired or dramatically change course all the time. Making strategic choices that recognize this and are at least partly proof to the winds of change may not be obvious to everyone at the time, but just about everyone can see them after the fact.
The first question from many of you will be “How do I know what will change, and when?”. The answer (of course) is that many times you won’t know precisely what will change, but you can often predict what is more likely to change. An example might be taxation rules or rates – if these factor into your decisions you had better assess the impact of them changing because you can be certain that over time they will!
Technology is a Tool, Not a Goal
I’m sure many of us know someone who just has to have the latest gadget or toy, and can find some “reason” why it’s valuable. We see the same thing in business surprisingly often – with the same lack of real results.
Weeding this out of your strategy can sometimes be a bit tougher than we think since simply not keeping pace with technology trends can mean death to some businesses. But even when we undertake pure technology modernization projects we should always consider whether we’re satisfying a true business need, and getting “value for money” compared to not doing it at all. If not, maybe we’re too focused on the technology, and not enough on the real goal.
No One Answer
Sometimes a single right answer may be unrealistic. A solution in one environment may simply add complexity or cause pain when applied to another. Don’t be afraid to choose two options if one is not enough. Or after reviewing all the options, the one where you do nothing at all may be the best!
Avoid Short Term Syndrome
How many “short-term” solutions become long term problems? It’s important to overcome resistance to looking forward, and to consider the same fundamentals – including future flexibility.
Agile Strategy
Finally, you might be wondering how the above fits alongside our stated preference for using an Agile approach to implementing technology solutions? My answer is that ultimately we believe the outcome is what is important, not the approach to getting there. Our current thinking (and we’re obviously not alone!) just happens to be that Agile approaches help organizations get there faster and more effectively than the alternatives right now.
To back this up from a slightly different perspective, Elisabeth Hendrickson recently discussed why she defines Agile in terms of results:
Where people define Agile in terms of practices, I see more instances of Cargo Cult adoption (”We’re Agile because we stand up every morning!”) and religious dogmatism (”You don’t TDD?!? You can’t possibly be Agile!”).
Where people define Agile in terms of values, I see more instances of Agile-as-an-excuse (”Documentation? No. We don’t document anything. We’re Agile!”).
But where people define Agile in terms of results, I see greater focus on the ultimate goal: value to the business.
I really couldn’t put it much better: attention to results keeps everyone focused on what’s ultimately important.
Are you tired of working with consulting companies who give you what you ask for, but not what you need? If you want to partner with us to extend your IT capabilities and produce real results, contact us
Heilmeier’s Catechism – a checklist for software projects
Until recently, I am ashamed to say that I had never heard of George Harry Heilmeier. A recent retweet by Roy Osherove on Twitter soon had me digging for more information.
It turns out that not only was Mr. Heilmeier a pioneering contributor to liquid crystal displays, he was a Vice President (and later CTO) of Texas Instruments during the time they produced the mighty Speak and Spell.
Mr Heilmeier’s Wikipedia page lists an amazing amount of awards, including the National Medal of Science and the IEEE Medal of Honor, but that’s not what sparked my curiousity.
What was interesting to me about Mr. Heilmeier was a series of questions anyone should be able to answer when proposing a research project or product development effort. These questions are known as Heilmeier’s Catechism.
Here is Heilmeier’s original list of questions:
Heilmeier’s Catechism
- What are you trying to do? Articulate your objectives using absolutely no jargon.
- How is it done today, and what are the limits of current practice?
- What’s new in your approach and why do you think it will be successful?
- Who cares?
- If you’re successful, what difference will it make?
- What are the risks and the payoffs?
- How much will it cost?
- How long will it take?
- What are the midterm and final “exams” to check for success?
When I read this list, it struck me that these questions could easily be adapted as a software project checklist.
With some small tweaks in language, this list becomes a standard project checklist that any consulting organization should work on with their customers to answer when deciding whether or not to go ahead with a project:
Project Checklist
- What is the underlying business problem we are trying to solve with this project?
- What happens today? Is this problem worked around with manual processes?
- What’s new in this approach and why do we think it will be successful?
- Who are the project stakeholders?
- If we’re successful, what difference will it make?
- What are the risks and the payoffs? How can the risks be mitigated?
- How much will it cost?
- How long will it take?
- How will we measure progress on the project? How do we know we’ve been successful?
What about your organization’s project approval process? Does your company use Heilmeier’s Catechism to decide whether to give a project a green light? What other questions should be asked before starting a project?
SOQL Group By – Grouping records in Salesforce.com
Overview
One of the most sought after features in SOQL (Salesforce.com Object Query Language) has been the inclusion of record grouping. While Aggregate functions such as Min, Max, Count, and Sum have been available, they have not been available to retrieve grouped Aggregate results. For example, if you wanted to retrieve the Count and Sum(Amount) of Opportunity Records grouped by an Account, you have to retrieve all of the Opportunities and create a loop to increment Counts and Sum based on the Account associated with the Opportunity. Ugly!
With the introduction of the Salesforce Platform Winter 2010 release and version 18 of the API, grouping and a few other functions are available. In this post I will concentrate on the “GROUP BY” clause. In future posts, I will examine other clauses such as:
- GROUP BY ROLLUP ()
- GROUPING ()
- GROUP BY CUBE ()
- HAVING ()
EXAMPLE
In this example, I want to showcase the different types of Grouping and Aggregate Functions that can be combined to come up with some interesting results. I want to create a Visual Force Page bound to a Custom Controller, where I can display the results of the SOQL statement.
First, let’s start with the Controller code. I wanted to bind the results of the query directly to a apex:dataTable, so I created an object to hold the Grouping values and Aggregated results. Below is the object:
public class GroupedQuery
{
public string GroupBy1 {get;set;}
public string GroupBy2 {get;set;}
public string GroupBy3 {get;set;}
public integer Count {get;set;}
public Decimal Sum {get;set;}
public Decimal Average {get;set;}
public Decimal Min {get;set;}
public Decimal Max {get;set;}
}
In addition, in order to bind an object to the dataTable within the Visual Force page, you need to expose a public member from your Controller code. For brevity sake, I just added a public List<> member like this:
public List<GroupedQuery> queryResults {get;set;}
Next in the Controller Constructor (keep in mind this is for demo purposes!) we use a SOQL query to retrieve a List of generic sObjects:
List<sObject> queries = [select Account.Name AccountName, Count(Name) CountResult
from Opportunity group by Account.Name];
Once we have the Results we iterate through a loop to create our collection of GroupedQuery objects:
queryResults = new List<GroupedQuery>();
for (sObject query: queries)
{
GroupedQuery myObject = new GroupedQuery();
myObject.Count = Integer.valueOf(query.get('CountResult'));
myObject.GroupBy1 = String.valueOf(query.get('AccountName'));
queryResults.Add(myObject);
}
The variable queryResults is exposed as a public variable from the controller and thus we can tie this List directly to a dataTable and access the public properties of the GroupedQuery object contained in the List. Below is the Visual Force page code:
<apex:dataTable id="queryResults" value="{!queryResults}"
var="queryResultsRow" border="1" width="100%">
<apex:column >
<apex:facet name="header">GroupBy1</apex:facet>
{!queryResultsRow.GroupBy1}
</apex:column>
<apex:column >
<apex:facet name="header">Count</apex:facet>
{!queryResultsRow.Count}
</apex:column>
</apex:dataTable>
The code above will output the following results (the Account data is data from the Developer Edition of Salesforce.com)
A more involved example is included below. This includes two levels of grouping, as well as Min, Max, Sum and Average functions:
Summary
As demonstrated, the new functionality released with the Salesforce.com API Version 18 with regards to Grouping is extremely powerful and addresses a pain point that many developers have had to overcome to achieve Rollup type queries. This information is contained within the What’s New notes for Salesforce.com Version 18. Keep in mind this is included with the Winter 2010 release of the Salesforce.com platform, so you will need to ensure that your organization has been upgraded in order to avail of this functionality.
Are you tired of working with consulting companies who give you what you ask for, but not what you need? If you want to partner with us to extend your IT capabilities and produce real results, contact us
{
public string GroupBy1 {get;set;}
public string GroupBy2 {get;set;}
public string GroupBy3 {get;set;}
public integer Count {get;set;}
public Decimal Sum {get;set;}
public Decimal Average {get;set;}
public Decimal Min {get;set;}
public Decimal Max {get;set;}
}
It hurts when I do this – an open letter to Software Consultants
There’s an old joke that goes something like this:
A young woman went to her doctor complaining of pain.”Where are you hurting?” asked the doctor.
“You have to help me, I hurt all over”, said the woman.
“What do you mean, all over?” asked the doctor, “be a little more specific.”
“The woman touched her right knee with her index finger and yelled, “Ow, that hurts.” Then she touched her left cheek and again yelled, “Ouch! That hurts, too.” Then she touched her right earlobe, “Ow, even THAT hurts”, she cried.
The doctor checked her thoughtfully for a moment and told her his diagnosis; “You have a broken finger.”
So what does this have to do with software development?
Too many times consulting companies get customers to tell them what they want and then they build it. What’s wrong with that? Isn’t there an old saying that says the customer is always right?
If you build what the customer asks for without digging deeper into the underlying business problem, then I guarantee that you will not build what they need. If you are just delivering a technical solution to a customer without figuring out whether you are solving the right problem in the best way, you aren’t giving your customer value for money. In fact, no matter how low you put your rates, you are short changing your customers, because you are charging them money to not fix their problems.
Just like a doctor’s patient can describe their symptoms, but doesn’t necessarily know the correct prescription to cure their ills, a customer is typically able to describe the business problem they are facing – but that doesn’t always make them the best person to come up with the solution. You need to collaborate with the customer and dig deeper to understand what the underlying issues are.
Of course, the customer is typically the expert in their domain and you should be the expert in yours, but you have to be more than just a technical expert to deliver business value. You need to be creative and passionate, you need to establish trust with the customer and build a collective sense of ownership of the problem so that you and the customer can both contribute to the solution.
You can use techniques like the Five Whys to perform root cause analysis, but ultimately you need to be interested and involved with your customers and care about their business. Only after defining the root cause of the problem can you then relate the problem to a solution you can provide with your domain expertise.
Ultimately, it’s not about delivering a project on time and under budget if that project isn’t effective; only by helping your customers succeed have you given value for money.
Are you tired of working with consulting companies who give you what you ask for, but not what you need? If you want to partner with us to extend your IT capabilities and produce real results, contact us