Entries for 'timbryce'

 Quality must be built into the product during design, not inspected in afterwards. Beyond the mechanics of quality though, people must learn to care about the work products they are charged to produce.  Quality requires both discipline and a conscientious work force. You cannot have one without the other.

Okay, you believe you had a great day at work today; that you accomplished a lot. Maybe you did. Then again, maybe you didn't do as much as you might think. A lot of people believe just because they are a model of efficiency, they are being highly productive. This is simply not true. We have discussed the concept of productivity on more than one occasion in this column, but some trends in the business world have caused me to revisit it again.

My single most important recommendation to anyone considering the use of outside consultants is simple: Get everything in writing! Clearly define the work assignment, get a signed agreement spelling out the terms of the assignment, and demand regular status reports.

I am always amazed how companies give consulting firms carte blanche to perform project work as they see fit. Abdicating total control to a consultant is not only irresponsible, it is highly suspicious and may represent collusion and kickbacks.

There is nothing magical in managing consultants. It requires nothing more than simple planning, organization, and control. If you are not willing to do this, then do not be surprised with the results produced. Failure to manage a consultant properly or to adequately inspect work in progress will produce inadequate results. So, do yourself (and your company) a favor, do your homework and create a win-win scenario for both the consultant and yourself.

 

The design of major systems need not be a complicated process couched in a cryptic vocabulary using seemingly esoteric techniques. While the state of the art in programming has undergone considerable changes over the last half century, little progress has been made in the area of systems which has stagnated due to the lack of standards and the heavy emphasis on programming.

Nonetheless, it's a new year, and time to go back to work. January is when we reset the statistics, brace for a new year, and try to prove ourselves once again. Some people have trouble getting back into the swing of work after the holidays; they've probably slept too much, partied too much, and ate way too much, which explains the five-to-eight pounds they've put on. This is why dieting and temperance are among the top New Year's resolutions. Regardless, they are having trouble focusing on their work.

Quality and service used to be considered paramount in this country. If it wasn't just right, you were expected to do it over again until you got it right. We cared about what we produced because it was a reflection of our personal character and integrity. But somewhere along the line we lost our way and craftsmanship has fallen by the wayside. Why? Probably because we no longer care.

Are we really trying to promote teamwork or is this nothing more than the latest corporate fad that is being implemented more for public relations than anything else? Let's hope for the former and not the latter. Teamwork is a powerful concept, particularly when there is anything of substance to be done.

Estimating is one of the most controversial subjects in project management. There are some people who have turned the subject into a cryptic science involving esoteric techniques. Estimating is simply the process used to determine the amount of effort and cost required to implement a project, in part or in full. It is important to acknowledge that...

The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. 

Watching the speed by which Information Technology (I.T.) has changed over the last forty years has been amazing. Hardly a day goes by without some new twist or invention. In particular, my interest is in how I.T. can be applied to support the systems needed to operate a business, such as for manufacturing, inventory, order processing, customer service, accounting, human resources, and much more. I have seen a lot during the last four decades, perhaps too much.

It appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design. Information Driven Design begins with a simple concept...

While others are moving forward introducing new banking products, the Americans find themselves in the role of constantly fighting fires. You cannot move forward until you put your house in order by bringing standard practices and discipline into your work effort. This is what happens when you treat system design as an art form, as opposed to a science.

In addition to the fundamental duties and responsibilities of an employee, it is not uncommon for workers to misunderstand their various project assignments. Consequently time and money is lost as employees try to delineate their responsibilities, including their relationship with co-workers.

There are several interpretations of Business Process Design, which is concerned with devising a cost-effective approach for the various tasks to be performed in a business. Here is mine which has worked effectively for me for several years. It's not a matter of what tools I use, but rather understanding the principles behind the design process itself.

In a recent Information Technology discussion group I am involved with, someone posed the question, "What is complexity?" I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design...