Information Technology Consulting Services

We recently had a situation where one of our candidates was working with more than one firm.  This is not too un-common; I have touched on this subject before in this post here.  The other firm did not do a very good job of presenting this person.  They probably slapped their logo on his resume and sent it off to the client along with a number of others that “looked good”.  The candidate did not hear anything from the other firm. 

We, on the other hand, took time to understand this person and used our Now you know^TM assessment to get an un-biased gauge of his skills.  We found him to be very strong in the skills that several of our clients were looking for.  We talked with him on where we would like to present him and that’s when we learned of a potential conflict.  A quick call to the client confirmed the client was working with another firm as well and if he was submitted by them, they would get the credit.  BTW, what’s his name?

Fortunately, we are members of Techserve Alliance and industry best practices in this case call for the candidate to decide who should represent him at the client.  We have a Right to represent form that we had the candidate fill out for this client.  That way there is no conflict. 

The moral of the story is this: If you are a candidate, make sure the firms you are working with are doing a good job of representing you and know where they are sending your resume.  We recommend that you work with no more than 2 firms.  If there is a conflict, then you should decide who is doing a better job of representing you.

If you are on the hiring side, and hiring for IT, then hire an IT staffing firm, not someone that does several types of jobs.  Don’t let them sell you on how deep their database is, according to the latest Techserve Alliance operating metrics report, less that 30% of the positions are filled from their own proprietary database.  (Ours is over 50% because we are focused on IT in the Cincinnati and Dayton areas).  We all have access to the same internet resources.  If all you needed was a stack of resumes that has been poorly scrutinized, most staff augmentation firms would be fine.  But you don't have time to cull through 20 resumes to find the person with the real experience.  Isn't that what you're paying that staffing firm to do?

All enterprise application development team members know that an IT business solution project goes through a Project Life Cycle (PLC) from initiation through deployment and closure. It is also well known that the Project Manager plans the project during initiation to prepare to bring the project to a successful completion by ensuring that all application software development resources are available to the project when they are needed.
 

However, many people believe that the Business Analyst’s (BA) role on the project is to capture the business requirements for the IT business solution. Business analysis professionals know that there are Project Planning tasks for the BA to perform on the project.
 

The Business Analyst should be assigned to the project during the initiation phase about the same time as the Project Manager, assuming this is a different BA than developed the Business Case for the project.  If not, then the Business Analyst is already assigned and working on the project when the Project Manager gets assigned and should move from developing the Business Case to Planning the Business Analysis activities for the project.
 

Project Planning, or more commonly called Business Analysis Planning and Monitoring, includes planning the Business Analysis approach, conducting a stakeholder analysis, planning the Business Analysis activities, planning Business Analysis communication, developing a work breakdown structure (WBS) if necessary and planning the Requirements Management process to be used on the project.
 

Cincinnati and Dayton companies, as well as those across the globe, can benefit by engaging the Business Analyst during the Project Planning and gain reduced project timelines, better resource utilization, freeing up project resources sooner, less re-work and increased probability of project success.

Does your company engage the BA for Business Analysis Planning and Monitoring?

One of the most strategic roles of the Business Analyst (BA) is that of a Management Consultant. This role is not drawn out by the IIBA® in the Business Analysis Body of Knowledge® (BABOK®), but it would fall in the Enterprise Analysis knowledge area. Perhaps this role will be given its due recognition in the Business Analysis Body of Knowledge Guide version 3.0 now being developed.

The Business Analyst, Enterprise Analyst (EA) or Enterprise Architect (EA) as they are sometimes called in this role, is often engaged in enterprise wide or market research activities that gives the person great insight into the organization and the market(s) in which it operates. Such activities as feasibility studies, market research, product analysis, SWOT analysis, Capability Gap analysis, analyzing business issues and opportunities, root cause analysis, defining business needs, developing business cases and documenting business processes gives the analyst a deeper understanding of the business and the environment in which it operates that sometimes even the senior management of the organization does not have. This is not saying that business analysts are smarter than business management, it is saying that analysts get deeper into the details of the analysis, which can derive greater understanding of these details about the business.

The creation of internal IT Consulting groups is becoming a common place in companies; in particular a few organizations here in Cincinnati and Dayton in which I have consulted. These groups are often created to perform business analysis activities on the enterprise level; to consult the business on the capabilities and limitations of technology and to consult enterprise application development teams on business needs and requirements. Whether BAs, or the IT Consulting Group, is consulting executive management or business lines management; this is consulting business management to take advantage of business opportunities and diminish business weaknesses and issues.

The creation of an internal IT Consulting Group shows great emphasis to business analysis within the organization. Even if your organization is not large enough to justify a formal IT Consulting Group, giving emphasis to business analysis as management consultants helps the business management make more informed decisions, helps the organization better accomplish its strategic goals and initiatives and enables better change management.

How does your company utilize business analysis for strategic value?

One of the strategic roles that the Business Analyst (BA); Enterprise Analyst (EA) or Enterprise Architect (EA), can perform for the organization is the maintenance of an internal knowledge base, often called an internal Business Analysis Body of Knowledge.  This would be a centralized, electronic repository of artifacts concerning the organization and the environment in which it operates.  This is not a task defined in the IIBA® BABOK®, however would fall under the knowledge area of Enterprise Analysis.

This repository should describe not only the organization but the environment in which it operates. It should include an Enterprise Architecture; divided into Business Architecture, Information Architecture, Application Architecture, Technology Architecture and Security Architecture.  Along with that it should include BA training and information material to quickly ramp up newly hired Business Analysts.  Also, some type of mechanism to ensure you are capturing the business knowledge of Business Analysts who are leaving the organization, so that valuable business knowledge does not walk out the door.

When a Cincinnati, Dayton or other community business has a BA community that is actively maintaining a centralized, electronic internal body of knowledge; that organization is well on a maturity path from a BA Practice to a Business Analysis Center of Excellence (BACoE).

By maintaining this body of knowledge within the organization, the Cincinnati, Dayton or organizations across the country and globe can help deliver business analysis services across the organization at the same level of service, move its business analysts among the business lines and business units within the organization with ease and little ramp-up time, make better business decisions based on an enterprise-wide knowledge base, enable business management consulting within the organization.  These business decisions can have significant impact on the company’s bottom line.

Does your organization have an internal business analysis body of knowledge?

We have been discussing the value a Business Analyst (BA) brings to the table in the area of Solution Validation.  Another often overlooked and underperformed task of Solution Validation is “Assessing the Solution Performance”.  Cincinnati and Dayton organizations do not take advantage of the benefits that can be received by performing a Solution Performance Assessment.

This task is performed after the IT business solution is deployed and working.  It can be done very shortly after implementation or over a period of time following deployment.  You cannot assess performance if the solution is not in use by the business.

First the BA must determine the criteria by which the solution will be measured; these are often called “key performance indicators” (KPI).  To determine correct performance criteria the BA must understand the intended value that the IT business solution was designed to deliver to the organization.  Understanding this value the BA may determine criteria by which the solution may be measured to determine if the business is receiving the anticipated value from the solution.

Some of these solution performance metrics may be quantitative, measure of time, volume, revenue, errors or other hard numbers; or qualitative, user satisfaction and use, recommendations, concerns or other subjective opinions of the stakeholders using the solution.  When a new enhancement to the Order Entry system in deployed, but you soon find that the Customer Service Representatives or Order Entry Clerks have developed a manual workaround that circumvents the enhancement, then your qualitative analysis would show a negative response from the stakeholders.  Such response should be investigated by the BA or Subject Matter Expert (SME) to determine the root cause of the business user’s dissatisfaction with the solution.  This may lead to enhancement, reversal or replacement of the IT business solution.

Collecting solution performance metrics are not only negative, but the BA should also collect positive metrics to assist in determining if the solution is delivering the expected benefit to the company.  This can assist in early detection of a “bad” solution, proving the success of an IT business solution and can lead into other business capability gap analysis.

Does your Cincinnati or Dayton company collect solution performance metrics following project implementation?  What other ways have you found to validate the performance of an IT business solution after deployment?

One of the most important duties of the BA role within an organization is to be the “bridge” or “translator” between the business side and technical side of the business.  It takes excellent interpersonal skills, especially communication skills to perform this role; and the BA is the role within the organization that is in prime position to accomplish this goal.

Organizations whether in Cincinnati, Dayton or other business community, have different internal structures and utilize BAs differently.  Whether the BA reports to the business side or the technical side of the organization, their duty to foster understanding is the same.  Some organizations have BAs that work on the business side of the organization, these BAs are often called Enterprise Analysts or Enterprise Architects; and BAs that work with the technical teams of the organization, these BAs are often called Systems Analyst or Business Systems Analysts.  Often the stakeholders on both sides of the fence work with their BAs and the BAs on the business side and technical side work with each other to drive change within the organization. 

Issues arise when the enterprise application development team does not understand the requirements and their importance and priorities.  Issues also arise when business stakeholders do not understand what the IT business solution that the technical team intends to deliver.  The BA is charged to work through these issues and foster understanding of each stakeholder’s goals, requirements and solution needs.  The BA can best accomplish this goal by developing a shared dialog and vocabulary between the stakeholders.  Each side needs to understand, at least in part, the other sides’ terminology and acronyms.  Shared terminology can go a long way to foster understanding.

By building the bridge of communication and understanding between the different teams within the organization the BA can help reduce project timelines, reduce project communication (overhead) needs, better utilize project resources and possibly gain greater project portfolio management.   So a BA needs to always be improving their communication and negotiating skills to better facilitate understanding within the organization.

As a Business Analyst (BA) we are often asked to help design a new user interface and the supporting application to perform a required function in the Enterprise Resource Planning (ERP) system. If you are talking about a web interface you may work with a graphic designer, or perhaps not.  You go off with your business application development design team and create a mock-up of the interface and write a design specification describing how it is to be built. Often the business is not represented on the design team. The design team may pass the mock-up and design specification by a business Subject Matter Expert (SME) before attempting to get it approved; but then they are often approved by a business manager without ever being seen by the end-users that will actually use the new application. Often, features and function are primary concerns when the design is being created. What if we change focus of our design team?

I would like to introduce two concepts to which I have been recently introduced—Personas and Usability Testing. These two concepts are the main concepts of User Experience Practices. The purpose of User Experience Practices is to change the focus of the design team from features and function to the users the new application is to serve and usability of the application. Have you ever rolled out a new application and user interface to find out that the users hated it or even worse refused to use it? Have you heard of times new applications were rolled out but they did not make the user’s job easier or save them time or have any added benefit to the organization? Designing for User Experience would have changed those outcomes. Let’s look at these two components and see how they are used.

A Persona is an artifact (written document) that consists of a narrative relating to a specific user group. It should include a picture and an abstract name that you can live with.  So don’t name your Persona Mickey Mouse, name it Stan, Ned, Alain, or Liza instead. You don’t name them after actual people in the organization but use an abstract name that represents a group of people. Say you are a BA working with a design team that has been charged with designing a new Order Entry system. So what user groups (customers) is your new application going to serve—Order Entry/Customer Service clerks. Yes, the company has six manufacturing locations with at least two Order Entry clerks in each location; the larger facilities have as many as eight Order Entry clerks. So what Personas do you have—one local Order Entry Clerk, let’s name her Emily and she represents eight order entry clerks. In some instances you may find it necessary to have two Personas to represent this one group. The remote site Order Entry clerks will be represented by one or more personas. Who else—what about Sales Representatives that can enter orders as well. The Company has 16 Sales Representatives; 13 of which enter orders on a weekly basis, one who will enter an order or two every month and two who never enter orders. Sounds like three more personas, maybe more. Not considering reports that Sales or Upper Management will want out of the system, as these are often pulled out of the database after the Order has been entered; what about Inventory Management/Purchasing. If an Order Entry clerk enters an order that uses any extraordinary large amount of a raw material if Purchasing is not aware of it until tomorrow’s report comes out, in a day or two the manufacturing plant may be out of that raw material. Therefore, my Order Entry system must send an “alert” message to Purchasing for extremely large orders so that they can account for that material used and keep the manufacturing plant working. How about external customers who have to get the order to our company, they have to call the Customer Service Representative (CSR), how long do they have to stay on the phone with the CSR to get the order in. What if the customer sends their order in via EDI; so an IT persona is needed. Fax, email, XML file—all acceptable ways of receiving a customer’s order; these are often handled by a CSR or IT, but we may want to build an automatic process to enter these customer orders. These methods of order entry need to be specified on the external customer, CSR and IT personas.

The Persona Map—now that you have written all your personas, we need to focus on the important people that our new interface and application will be used to support. So take a very large cardboard poster and draw a target (bulls-eye). In the very center will be our Primary Persona. The one most affected by our new interface, probably the CSR/Order Entry clerks; but you can only have one, so we select Emily. In the inner ring of the target you can place two to three Secondary Personas. In our example, this most likely will be other local CSRs and remote CSRs.   In the outer ring of the target you can place three to four Tributary Personas. For our example, possibly Sales Representatives Personas and possibly IT personas. Now this Persona Map should be hung in the room where the design team will work, or if necessary duplicated and given to every design team member. Now we have changed the focus of the design team from features and function to the people who will use the new interface and application.

This is the first step of designing for User Experience. In my next post we shall explore the second step—Usability Testing. Even without knowing about Usability Testing, can you see the power that Personas can have?

For those of you who have wondered where I have been, I am happy to say that I was in the Bahamas.  I took a long deserved vacation with the family to the Bahamas.  The cruise and the trip were excellent.  Now I come from the 80 degree sunny weather of the Bahamas and Florida to the 20 degree snowy weather of Cincinnati, it just doesn’t seem fair.  No, I was not in the Bahamas for a month or two months, but getting caught up with everything takes time.

Recently, I have been pondering the question “Has IT become irresponsive to business requests?”  As I go from organization to organization I look at the time it takes from request to solution implementation and I am dumbfounded.  For those of us who have been in application development services for awhile remember that what use to take a day now takes a week, or longer.  Yes, we have things like Sarbanes-Oxley (SOX) and other regulations to thank for this; but also I see that organizations themselves put so much process into their developing of IT business solutions, that the time to fill a business request gets longer and longer.  Let’s take a look back to see how this happened.

In the beginning there was chaos.  The business manager, needing a widget, made a request to the IT manager, the IT manager handed down the request to the developer, who spoke this language called “techie”.  In three days, the business manager needing his widget, went to the IT manager and asked “Hey, where is my widget?”  The IT manager replied, “I will find out for you”.  He went to the developer and asked ‘Where is the widget?”, and the developer handed him a midget.  The IT manager said “I am not sure this is what he wanted”.  The IT manager returned to the business manager with the midget.  The business manager said “That is not what I asked for, can’t you understand plain ‘biz talk’?”  He further inquired, “Why couldn’t you tell me when it would be done and stop the developer when he started building the wrong thing?”  The IT manager said “I need help!” and chaos ensued.

Then The Project Manager (PM) stood up and said I can help.  I can put together a project schedule and draw pretty pictures for you that will tell you exactly when that IT business solution will be done.  The IT manager said “I like pretty pictures, yes do that”.  So the business manager made a request to the IT manager for a fidget.  The IT manager handed down the request to the PM.  The PM made a project schedule, carefully drafted a project scope, wrote a communication plan and a risk mitigation plan and made deadlines and milestones.  He then showed all his work to the IT manager who looked at it in awe.  Then the PM handed all his work to the developer who stripped out just the parts he needed to create the widget.  In seven days, the business manager needing his fidget, went to the IT manager and asked “Hey, where is my fidget?”  The IT manager showed the business manager all that the PM created and the business manager looked at it in confusion.  The IT manager said, this says your fidget will be done in two days.  The business manager said, at least now you can tell me when it will be done, but what is taking so long?  So now they have structure to the chaos.  In two days the IT manager delivered the widget to the business manager and the business manager said “that is not a fidget, what is wrong with you?”  The IT manager said I do not understand what you want.

So the Business Analyst (BA) stood up and said I can help.  He said your application development team speaks “techie” and the business people talk “biz talk”.  I speak both languages and can translate what the business is asking for into “techie” for the development team.  The IT manager said “Yes, do that”.  So the business manager requested a zidget from the IT manager.  The IT manager handed the request down to the BA and the PM.  The BA went and talked to the business manager and said “tell me about this zidget you want”.  He made long lists of requirements and definitions of what a zidget is.  Meanwhile, the PM made his project schedule, full of scope, plans and drawings.  The BA went to the PM and handed him all the requirements and said this is what the business means by a zidget.  The PM handed all that the BA and the PM had created to the developer who stripped out just the parts he needed to create this zydget.  In ten days, the business manager needing his zidget, went to the IT manager and asked “Where is my zidget?”  The IT manager showed the business manager all that the PM and BA had created, who looked at it in great confusion, and stated “Is that what I asked for?”  The IT manager said “Yes it is, and it will be ready in two days”.  The developer showed the finished zydget to the BA, who stated “this is not quite right, make a little change here”.  So the developer did as the BA said.  In two days the IT manager delivered the zidget to the business manager, who declared “Look you got it right!”

The above story does not really account for the time and effort that Quality Control and Production Change Control put into the process.  So it is easy to see why a day has become a week, or longer; and make it appear as if IT has become irresponsive to business requests.  However, in most organizations the above is the normal process, we call project life cycle (PLC), to get an enterprise application development change made.   Most organizations have emergency procedures that circumvent the normal procedures to get a change made quickly.  More and more I see those emergency procedures being used.  What does this cause, new production change control processes and validation, which usually translates into more people.  So what can be done to improve this process?  Go back to Chaos?
 

In an earlier blog post, I wrote about the dangers of working in IT. It is very important for application development people and really anyone who has a desk job to get regular exercise. My shocking moment was when I went to London with my son, and I saw myself walking across Abbey Road. There I am, and my “overhang”! To put more fuel on my weight fire, my boss is doing P90X. He has dropped several pant sizes and is looking good. To figure out how I was to lose weight, I did what all good application development people do, I observe what works for others. I recently read (and saw his picture) that Drew Carey lost 90 pounds in 8 months. His secret for his weight loss was getting on the treadmill for at least 30 minutes everyday, and eating broccoli. I looked at people who run regularly, and they are skinny! So I decided to run and eat broccoli. My diet currently consists of an apple in the morning, turkey for lunch, a banana in the afternoon, a protein shake after my run, broccoli, a small dinner, and maybe some skinny cow ice cream. This may be too much for some, but try these simple things to start: drink water instead of soda pop. Swap out a candy bar with a piece of fruit. As for the running, I go six times a week. I created a “course” at an executive park by my house. My first time, I barely got through a half mile. It doesn't really matter how far you go, just set a goal for yourself. Every day I wanted to go further, and eventually my course became three quarter of a mile. I found this Android app that is my favorite and most useful piece of software I have used. It's called Cardio Trainer. It uses GPS and Google Maps to track your running. It keeps track of you distance, time, and calories burned. I save my workouts, and now I have a history of my runs! In six weeks I am up to 16.5 miles a week while running three 5Ks in my training. I have lost at least 12 pounds (I am sure I have added muscle to my legs). My “overhang” has dramatically decreased, I have more energy, I sleep better, and I feel happier. The point of my story is that we application development folk need to get up and do something. If you have bad knees, try swimming. Find something that will make you active. Set a reachable goal, achieve it and set another one. I want you guys to hang around and read my stuff!

On of the big things all application development people know (and I guess business development people know as well), is how their department is treated by management. This battle has been raging since companies decided to have an IT department. The perfect company would have an IT department that supports the business goals and objectives, and can scale and change quickly. I can hear some application development folks laughter already. It can happen. Management needs to let the IT department make the decisions on the software, hardware and infrastructure. IT must understand the business needs, and managements' objectives. The business needs to articulate their needs, and help IT understand the business concerns. In balance, all departments fulfill their roles and the business grows. I have seen some companies that at least understand this principle, and try to implement it, but most companies have one side dominating the other. I will highlight the major factors for the Great IT Battle.

Management treats IT as a cost center – That is correct only if you are an accounting firm. IT brings great value to any organization by streamlining your business processes, which gives you your competitive advantage. I think that more than justifies the cost.

Business “owns” the IT department – This is very common where the business was mature before IT was around. Management came from the business, and doesn't understand that IT is a separate department. IT cannot scale and maintain their infrastructure, so once every 5 – 7 years there is a project like the Big Dig. If you like complex, over budget projects, continue in this manner.

IT “owns” the business - This is  common with organizations that see growth when they added IT. Usually this is caused by management thinking that IT solves all of the problems. IT supports the business. You still need a business plan and a vision.

Political battles between the three – This is the crux of the issue. Management usually comes from the business side, so when in a political battle, IT loses. Unless management views IT as the “magic bullet”, then IT wins. All political battles boil down to my next point:

Risk aversion - an executive at one of my clients pointed this out to me. All of the executives are the winners of many years of political battles. Any decision made is with the idea that they are near retirement, and will not make any drastic change that could hurt their position.

There are a lot of other factors that nuance these scenarios, so your view to the struggle is unique. We at STAR BASE would like to know where you are in this struggle by taking a brief (17 questions on 1 page) survey. STAR BASE can help your organization call a truce to the Great IT wars.

See Part One here.  These deadly sins are not limited to IT Consulting in Cincinnati, but everywhere.  I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

5. Blame it on Rio.  And I am not talking about the movie, I am talking about pushing the mistake/error onto something else like, the Operating System, another consultant or worse, one of the client’s employees.  While the problem could very well be any of those things, your job as a professional consultant is to find solutions and to set an example in leadership and even diplomacy.  While you may see glaring errors or mistakes and perhaps your way would have been the better way to do something it is best to keep the criticism and commentary to yourself. (See #3 in Part One)

6. Bubble gum and baling wire.  Many times consultants are brought in to fix something.  The last thing you want to do is to take a shortcut that you aren't sure will last. Band-Aids are fine if you know you are coming back to make a more permanent fix. But eventually, those shortcuts will fail and will need further attention and the time to failure is an unknown. It could be the minute you drive away or months later. This is not the type of chance you want to take. It frustrates the client, and it makes you look bad.  You also don’t want to make the client totally dependent on you.  A client told me once that Peter (not the real name) is very talented; the problem is he is the only one that knows how it works and can manage it.

7. Showing up, Gotta Go. (AKA I gotta hangnail).  Once you’re on a gig, most clients want to see you on some sort of regular basis and some might have a “core hours” expectation.  It’s important for both the client and the consultant to know what each should expect.  I once heard a client make a comment about another consultant that went something like this: “Larry(not the real name) runs out of here all the time and uses sickleave for a hang nail!” 

Here is another list that has some similar ideas here.  I’m sure there are others.  So go forth and sin no more!
 

You have probably heard your parents or grand-parents talk about when they were younger and how they had to walk to school, up hill both ways.  When they shared this story with you it was to prepare you for times when things weren’t so easy and to provide you with their knowledge and advice from their hard earned experience. I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

1. Bill for time not worked.  This will be the quickest way to end up out of a consulting gig. Make sure you bill the client only for the time you actually work. This can be tricky if your clients are friends. When you go to a job like this, you know there will be a period of time spent socializing, especially when you first arrive. Don't bill for this time. Start the billing period when you start working.  Sometimes clients will have celebrations during the day.  If you don’t want to appear anti-social, by not going, just don’t bill.  If there are any questions, ask the account manager to find out. If you are the account manager, ask your client manager at one of your one to one meetings if it’s ok to bill.  Some client’s have a culture where that is part of the expectation.

2. Negotiate rates and make deals with the client.  If you work for a consulting firm, you know there are channels for clients to go though to make requests..  Most firms have some sort of account manager to handle those issues.  Direct the client to the account manager.  I had one consultant that actually went so far as to look in the client’s AP system to see how much we were getting paid and then wanted to negotiate a higher rate with the client.  This particular action did not end well for the consultant and he has not been able to be considered for other assignments in this client even when his skill set was ideal.  Never, ever work out a side deal or moonlight with a client this can comprise your integrity and jeopardize the trust between  you, the consulting company and inevitably the client.

3. Act like a prima donna.  Yes, you’re good, that’s why you have been hired. I actually heard a consultant tell the client that their employees were stupid.  Hello? You are there to serve those employees.  You don’t know what kind of constraints they have had to work with.  Hind sight is always 20-20.  Its always far better to politely make suggestions. You may find out your brilliant idea was considered previously and there was a very valid reason for it not being implemented.  It’s much better to NOT have egg on your face or your foot in your mouth.

4. Miscommunicate or undercommunicate when engaged at a client I believe that the client should know what is going on with their project.  Many times I have had to be the bearer of bad news.  I also like weekly status reports to let the client know what I have worked on and what I’m planning on doing.  If at all possible I like to let them know a percent complete.  Years ago, I heard another consultant tell the client he was “unit testing”.  The client assumed that meant he had all the functionality done and was testing.  The reality was he had about 10% of the functionality done and was testing just that one small piece.  When the truth came out, it was not pretty.

Tomorrow I will finish off the last 3 sins.
To be continued……

In my recent post, I talked about my new phone for my upcoming trip to London. I am excited about my new phone, but not the cost. My carrier charges .35$ per outgoing SMS, .20$ per incoming SMS, and 15$ per MB for data. Since my phone is always “listening” on the Internet, it would cost a lot to actually use my phone in London. I can put my phone in “airplane” mode and use the camera, games, and music capabilities, but why have smartphone and not use its features? Fortunately, the solution is relatively simple. I can unlock my phone and use a pre-paid SIM card while in the UK. For my application development friends who are not phone savvy, let me explain. US phones are “locked” for US usage only. All carriers also make some phone features unavailable to the customer. In some cases, you are charged an additional fee for a feature your phone could perform for free! In this case however, I am unlocking my phone so I can use it on other networks. You may have heard of the term “Jail Breaked”.  This refers to a phone that has been hacked to allow all features on your phone to be used. Some phone manufacturers and carriers don’t like this, and can make your phone unusable, or “Brick” your phone. Unlocking through your carrier is perfectly fine though. Once your phone is unlocked, the second part is to get a SIM card in the country you are traveling to.The SIM card is how the network recognizes you. If you opened your phone and swapped your SIM card with a friend, you would get all of his calls, and he would get yours! You can pick up a prepaid SIM card with a data plan for about 10 pounds (approx. 15$) a week. That’s a hefty monthly bill for a local customer, but it is much cheaper than the roaming plan. Remember, your phone number is different with a different SIM card! I can use my phone features to post messages and images on Facebook, for example, like I was at home. I can communicate with people at home without paying hundreds! I will let you know how this works out when I return.

I am now in my second stint as a performance architect. There are many tools to measure performance. Usually there is some criteria like time or memory that is failing. I think most application development people know that the secret to good performance is good code. The problem is that good code is impossible to measure. There isn’t any metric you can show your boss that shows refactoring this class will make the code run faster, or at least will not remove that class from the performance list. Besides we have these new features that need to be added. So how do I make code perform at a high level?
Write unit tests. Make sure that the tests cover all of your method calls. Make sure that your test captures error situations, not just the "happy path". Write your test cases BEFORE you write your code so you can "code to the test". Of course, you need good use cases from your architect and business analyst to write the unit tests.
Comment your code. Make sure your method names describe the function it is performing. Most IDEs add the parameters and returns for you; all you have to do is describe the reason for the method. These are easy things to do. They are boring yes, but when it comes to adding that new feature, or changing a method call, it saves a lot of time when you can run a test to prove that your changes work.
Refactoring. All application development people should learn refactoring. The Java language has changed tremendously in the last 15 years, and your code hasn’t. I think that the Date object has been revamped twice since the 1.x days. New features like annotations and generics may not change the performance of the code, but it sure does affect the readability of the code. Readable, easy to understand code is also easy to maintain and update. It makes a six month project become a three month project. The business always has more projects, so they will be happy. Fewer errors happen, so your boss is happy. You get to solve more interesting problems so you are happy. When you are happy, both you and your code performs better.

My client has great code promotion rules. All code that changes gets system tested or it doesn’t get promoted. Code doesn’t change unless it has a bug tracking ticket. You say Matt, that’s great! Why is this a problem? The problem resides in the fact that everyone in IT is stretched to the limit, and deadlines are tight. Application development people are getting the code working with little refactoring, architects struggling to get the analysis piece out and little time for code review, and not enough testers. This situation makes it difficult for performance. As part of the performance team, I can review all of the code, and make some changes, but the problem is that if the code is not a part of the release, it will be impossible to get promoted due to time/resource constraints.
For example, a process was taking a long time to complete because of improper error handling, but the call is not necessary. The proper fix is to remove the call, but the fix going in only resolves the exception. Why? The low priority of the code, coupled with the testing constraints and lack of testers makes these changes common. Some application development people may say, "Well, the code is fixed". True the performance issue is resolved, but there is an unneeded call. If the attitude from application development people is "I would fix it, but it’s too much trouble to test", unneeded code can add up quickly. Extra code is in all projects, but if changes like this or, removing a variable passed to a method, or even changing code to remove unused variables don’t get fixed, the "extras" add up. Not one of these changes significantly affects performance, but all of them will. The solution is to work with management and your application development people to limit "extra" code. This can be done by reviewing and fixing code in your maintenance or enhancement project. Have a "refactoring time" built in to the project plan. The time put in up front will bring great dividends both in performance and future coding effort.