Window of Opportunity

August 8, 2009 Leave a comment

Whether you are doing Scrum, Extreme Programming or whatever you want to call it, “time” is a major driving factor in development. Companies are engaged in product wars where it is essential to have new products or functionality in place within a window of opportunity. Create a world class product but miss the window of opportunity you might as well not have developed anything at all.

Concept: Just in time development

The days of trying to plan what is needed in advance in detail and then develop everything at once are over. I am not saying not to do any planning at all. And I am not saying this concept implies working in an environment with little or no structure. I am saying do just enough planning at a high level but not spend a lot of time planning every detail. The future is going to be delivering value at the point of sale or close as possible to the point of sale. If you are using unvarying and predictive practices in software development you are no match for today’s volatile environment. In many cases we do not know what is fully needed or what functionality will be a big success until we get feedback. In addition, in some cases the really good feedback is not given or known until close to the end of a development cycle or release cycle. And in some special cases the point of sale. These are reasons to evolve a product quickly and efficiently as possible close to the end of the development cycle. Instead of anticipatory project management and development practices we should embrace the concept of “just in time adaptive development”.

Concept: Rapid iterations

One basic concept to being adaptive and being able to deliver value toward the point of sale is timing of rapid releases. Build, test and deploy core functionality and then add features in every release. Build a flexible base first and then add features rapidly later. All project deliverables such as vision, scope, design and code are developed in an iterative fashion.

When creating multiple version release plans make good decisions on what to deliver now and what features and functionality to defer. Develop high risk features first. If major changes are required to the architecture they can be completed early to minimize impact to the project. This means feedback is critical for these components. Major changes to the architecture late in a project life cycle usually requires a much bigger effort due to having to change more components and the added complexity of additional code supporting multiple features. In addition, core functionality should be delivered ASAP. What good is a solution that cannot be used for months? Deliver the core functionality first and then incorporate feedback in rapid subsequent iterations to add features. This means the base code must be flexible. By flexible I mean easily maintainable. The previous short sentence is the topics of many books about the details of creating quality code that is also easily maintained.

There are cases where it is not possible to actually deploy rapid versioned releases to the customer. In this case, you may consider an option to deploy to an environment where customer feedback can be solicited. This may be a controlled test site that simulates a real production environment. Rapid releases are deployed and feedback is solicited. Once the product has evolved to a certain point the product is deployed to the real production environment. You may be creative enough or be able to work with stakeholders to come up with other options that work.

See Figure 1 below:

Rapid Iterative Development

Working through iterations or releases quickly and maintaining manageable scope are key points so that iterations or releases are delivered within scheduled time frames and are of high quality. I am advocating that the releases be small. A few weeks of work at the most is included in any given release. A major down fall is to attempt to deliver way too much in each release especially the initial release. Doing this significantly increases the chance of missing scheduled time frames. Once behind in the development schedule you hope and think you will be able to make up ground in subsequent releases. But in my twenty plus years I have never seen this come to fruition.

Concept: Feedback loops

Shorting project feedback loops are a good thing if your project team and executives are willing to face reality early. Early, frequent and rapid feedback loops have the potential to save money and time by early termination or making early appropriate adaptations to software development projects.

Project team members and executives should constantly evaluate and make adjustments in four critical areas:
1). Product functionality.
2). Product quality.
3). Team performance.
4). Project status.

I like to call implementing feedback making refinements or evolution of the product. No software is perfect so corrections if needed are implemented at this time as well. Plans are just speculations therefore I like to use the terms like refinement, adaptation or product evolution. During a projects life cycle we are reacting to events rather than to a predictive plan. Success depends on constantly evaluating reality-based feedback. The process should embrace discovery and then act on what has been discovered and thus evolving.

Concept: Clear lines of responsibility, accountability and collaboration

In addition to the above mentioned concepts, your organization needs to have excellent collaboration and interaction among your relevant management groups. This means all aspects of your business are executing toward a common goal. Your IT strategy is in-sync with your business strategy. Roles and responsibilities should be clear and concise so everyone knows exactly who is responsible for what and when.

This is a brief introduction to the basic concepts. Each of the concepts mentioned above are complete topics in their own right. Many books and discussions are available for further reading. All I have done is to pull them all together here in hopes of showing you the most important concepts needed to achieve maximum value and hit your window of opportunity.

Web Design, Hosting and more!


Information Technology and Customer Service

January 28, 2009 Leave a comment

Service with a Smile

 The fact is that excellence in Information Technology or any job for that matter is all about customer service. In IT, it is not about the technology it is about the service and about the customer. Without the customer, there would be no job. Information Technology really could be called Information Services. It is a service provided to the customer and technology is the tool being used to help deliver the information.


Types of Customers.

There are two types of customers, internal and external. Internal customers are those internal business units supported by IT and can be referred to as employee to employee type relationships. Another type of customer is external to the company and can be referred to as employee to client, or employee to customer. Do not make the mistake thinking your work has such value that you can be flippant with your customers. The attitude that the customer is very lucky to have a person like me as an IT engineer is a big mistake. According to my experience I have seen successful people in IT excel because they know how to manage and maintain good relationships with their respective customers and not because of their superior technical skills. One example is, I worked for a company where there were two software engineers. Engineer number 1 was very knowledgeable and an expert in his field but was very flippant in his answers. The other engineer, number 2, was not so knowledgeable but his attitude was superior and he tried very hard to do the best he could. Engineer number 2, did not always know the answers immediately but would always follow up shortly with the correct answer. I found myself always going to the person who had the better attitude. Knowing I may not get an answer immediately did not discourage me. This goes to show you that a smile and a respectful attitude are keys to success and keys to having loyal customers. I believe in today’s competitive market this can be viewed as an added value.


Going beyond a respectful attitude.

Providing excellent customer service goes beyond smiling and having a respectful attitude. The real test is when your customer has a problem. How you handle the problem will determine if the customer will be loyal or the type of relationship you have with your customer. Sometimes we hear but do not listen. Often when people talk they are distracted and are only half way engaged in the conversation because they are busy thinking about a response while the other person is still talking. Many times this can lead to things being assumed and the listener not fully understanding the complete problem. One way around this is to listen first without being distracted and then formulate your response in a way that improves mutual understanding of the problem. This conveys to the customer that you really understood. If not, then the customer can explain some more. This technique can be used for clarifying communication and avoiding misunderstandings. This happened to me with a customer. The customer was having a crises with the software just implemented and was very upset. I was suddenly caught in an argument where I was busy formulating my immediate responses to the customers accusations. The conversation turned into an argument and the customer left visibly upset. I realized later that I should have suspended my judgment and listened first and then provide options on resolving the crises. As it turned out it was all a big misunderstanding of how the process really worked. Because of this incident I had to work extra hard to gain back the loyalty and trust from this customer. Customers know that you cannot always give them what they want but appreciate that you take the time to really listen to them and try hard to resolve their problems.


The interaction between people build great software.”

                                      Jeff Sutherland

                                      Chief Executive Officer

                                      Scrum, Inc.

Rapid Software Development

January 24, 2009 Leave a comment
Rapid Development

Rapid Development

Objective: Achieve rapid software development.

Software developers are usually under intense schedule pressure to “get it done”. The development time problem is pervasive. Most large projects miss the planned delivery date by 25 to 50 percent. In addition, I dare say that a good percentage of projects that span over a year in development time usually are way over the estimated completion date. The most critical issue facing the software development community is development speed.

Where does all the time go?


You can see by looking at Table 1-1 most of the time for small projects are spent in detailed design, coding and unit testing. If you could eliminate those activities, you would shave 65% off the development time. The most time expensive activities of large projects are architecture/design and detailed design. Cutting design time might seem like a good idea at first. It looks that time cut in design could shorten the project development time. What is more likely to happen is that any time saved will be paid back in later stages of the project. Think about this, a design error takes an hour or so to make corrections on paper. No code changes are involved. The same error detected during system testing could take anywhere from a few days to a month to correct. I have learned that the most effective strategy is to perform each development stage as efficiently as possible. I have actually reduced development time by spending more time in upstream activities such as design. This is because a typical project consumes around 40 percent correcting defective requirements. Correct these problems when they take less time in design. A good design saves time.

All she had done was to carve one more pattern in the mosaic of her identity, that constantly unfolding design which had been growing more intricate with each passing year. The mosaic would continue to grow…until in the final moment the design was complete.”
Jeri Taylor

Implementing ERP – Enterprise Resource Planning Systems

January 16, 2009 Leave a comment
My opinion

Ready for ERP?

What is ERP?

An enterprise wide information system is designed to take all information and collectively put it in one location to better coordinate and manage resources and activities needed for a particular business process.

Basically, ERP takes several major systems and puts them all together so that the software is integrated and runs on one central database.

Considerations when implementing an ERP.

You will conform to the ERP system. You will do business the way the ERP system dictates. This means all users will need training. All support personnel will need training. New procedures will be implemented by the ERP system that you and your staff will need know in order to function. In the contract negotiated between you and the ERP vendor, get as much training as you possible can get. You cannot have too much training. Remember you will be changing the way people do their jobs. Expect several years of training and learning. The vendor will quote you a much shorter time.

During the installation, it is essential for you to train your support staff. In the contract, specify that your staff will do the installation with the ERP vendor’s assistance. The installation should be done on site at your location. In addition, in the contract you should specify a “knowledge transfer” should take place. Do not let the ERP vendor install the package and leave. The central database is made up of thousands of database tables with hundreds of switches that control options for different processes. Your people must know all the installation details because they will need this knowledge later to support the package. You want your best people on the installation.
During the installation, install a clean unmodified system. DO NOT INSTALL a system that has been modified for you. The vendor could blame any problems on the modified version.

If there is a procedure you do not want to change in your current business practice, do not count on the ERP vendor to make changes in the package for you. They might say they will but if it is not in the contract, it will never happen.

Your customers, suppliers and others that access your system may need training as well. You might be able to create an interface for them so they can continue to send information the old way.

Since everything is in one central database and all software for all systems will be accessing it, you will have performance problems. The vendor will tell you that you will not. Nevertheless, you will. During month end is when you will experience the biggest performance problems. This is especially true when your finance department runs all their processes to close out month end. You will need to performance tune all queries paying special attention to month end processes. Put your best DBA’s and SQL tuning experts on the task.

Most packages require you to run the latest and greatest operating system and other software. You will be required to upgrade and stay on the latest version in order to install the new ERP releases. Also may be not right a way but within a year or so you will not be able to tune any more and a hardware upgrade will be necessary. Get ready to install upgrades frequently.

In the beginning, expect employee performance to go down because everything is new and procedures are different. People are not able to do their jobs like before. It is not easy changing people’s habits.

Everyting is integrated. What is your approach going to be?

Data Extraction and Conversion into the ERP system
I believe this is one of the most important activities of implementing an ERP. Do not underestimate the amount of time needed for extracting and converting data. Data to be extracted and converted needs to be identified. Timing of exactly when this is to be performed is critical. The data may need to be frozen for a specified period before extraction and conversion. Business processes may need to be suspended for the actual extraction and conversion to be completed during periods of low business activity. A detailed schedule of events is needed and both IT and the business unit should be on-board. In addition, do not forget a data-archiving plan.

Extraction out of ERP to feed other systems
Do not underestimate the amount of time you will spend extracting data from the ERP system to feed other systems such as a data warehouse. Selective data extractions from ERP systems can very hard to do.

It is often hard to find quality people who really know the system.

After you train your staff, you might be able to hire them back as consultants, ha!

Final thoughts
All critical processing that must be accomplished in a timely manner must be spelled out in the contract. If it is not in the contract, it will not happen. After you install the ERP package, you have no leverage to make the vendor do anything.