THE BRYCE IS RIGHT!

Software for the finest computer – The Mind

  • Tim’s YouTube Channel

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 946 other followers

  • Categories

  • Fan Page

  • Since 1971:
    "Software for the finest computer - The Mind"

    Follow me on Twitter: @timbryce

  • Subscribe

Posts Tagged ‘project management’

ESTIMATING – GETTING IT RIGHT

Posted by Tim Bryce on February 20, 2017

BRYCE ON PROJECT MANAGEMENT

– No Virginia, there is no magic in producing a project estimate.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I’ve long given up looking for panaceas. Actually, I have always regarded estimating as a relatively simple task and have taken my queue from the construction industry who has had to frequently produce reliable estimates over the years. As such, there are basically three variables involved:

* Methodology – defines the stages of work by which projects are completed, from beginning to end. Some portions of the project will be executed serially, others in parallel, either way, each stage should define precisely what work has to be accomplished to the types of components involved. Typically, components are identified, designed, tested, and installed in moderation which is commonly referred to as “stepwise refinement” (going from the general to the specific) as prescribed by the methodology.

* The components involved – in the construction field, it is the wood, stone, glass, nails, rivets, steel beams, etc. to be used to construct a building. In the I.T. field it is the data elements, records, files, input, outputs, programs, business processes, etc. The methodology dictates the sequence by which the components are implemented. A component assembled at the wrong time and place will likely prove disastrous, which is why the methodology is so important. To make this work, it is necessary to produce a rough design of the object in question. For construction, it would mean a complete rough design of a building, aka, “artist rendering.” In I.T., it would mean a complete rough design of a system or program. Only after the rough design has been completed can a listing of the components be identified.

Another consideration is the state of the components, how many are new versus how many can be reused from other projects. To illustrate, if there are already preexisting nuts and bolts to satisfy the product, they certainly can be reused; if not, new nuts and bolts have to be designed. Within a systems development project, if a data element such as “Customer Number” has already been invented and implemented, there is no point in introducing a redundant component; developers should simply reuse the existing data element. Such reusability of components not only expedites development time, but promotes integration of different products.

“Bill of Material Processors” (BOMP) are commonly used to keep track of components, be it in the construction field or I.T.

* The skill of the people charged with executing the project. A novice worker will obviously take longer to perform a given task than an experienced expert. This is also why it is preferable to have the people charged with the work participate in the estimating process as it becomes a reflection of their commitment. In a situation where project personnel are unknown, the Project Manager can still render an estimate based on “averages” defining the amount of time necessary to build a component for a given task. As projects are executed, the actual time expended to complete a component for a specific task should be captured so such averages can be refined based on historical data.

This approach to estimating is universally applicable to any product development based project. It is based on the recognition that most estimating errors are errors of omission, not commission. It is the forgotten or overlooked components that lead to most estimating errors. Again, this is why the rough design is so vital as it will overcome the problem of omissions. As in any construction project, a rough architectural design is required to effectively estimate the project to build it. The same is true in I.T. projects where the objective is to build a new system. To do so, a complete rough design of the system must first be prepared to effectively estimate the remainder of the project.

This approach also distinguishes the use of time as either “direct” or “indirect.” Whereas direct time represents whole work, indirect time represents interferences detracting from project execution. Estimates should be expressed in direct time, not indirect time, as we want to know the amount of pure effort needed to complete a component and task. This approach to time also implies estimating and scheduling are separate activities. Whereas, direct time is used to express estimates, indirect time is used to calculate schedules. For example, if an estimate for a project task is ten direct hours, and a worker is only able to spend four direct hours of work each day (with another four indirect hours spent elsewhere during the day), the task should be completed in 2.5 working days. Separating time into “direct” and “indirect” greatly improves precision in both estimates and schedules.

Here is a typical scenario for estimating a product related project, be it construction, I.T., manufacturing related, or whatever:

1. Specify and analyze requirements.

2. Prepare a rough design of a product to satisfy the requirements.

3. Prepare an itemized listing of components to be used in the product, aka, “Bill of Materials,” identifying which are new and which can be reused.

4. Based on the materials, define the remaining stages of work to develop the product (the methodology).

5. Estimate the amount of time necessary to complete the various stages. If project personnel are known, have them participate in the estimating process.

6. After the estimate has been defined, calculate the project schedule based on the methodology and use of time (direct vs. indirect).

7. Review with the client for approval.

This approach is certainly not new and has been used for many years in a variety of industries. Ultimately it represents a complete mental execution of the project in order to determine costs. This is essentially no different than what a professional golfer does before swinging his club on a drive; he visualizes everything from how he is to swing the club, the follow through, to where he wants the ball to land, and the ensuing strokes necessary to complete the hole. Preparing a rough design is no different. It is thinking the project through to completion by considering all of the components needed to satisfy the product. Will it be perfect? No, but it will be more accurate than making wild guesses based on some wild pseudoscientific calculation. The only drawback to it though is it requires some hard work in upfront planning and design; it is certainly not a panacea, but then again, there never has been any magic in estimating that I know of.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 40 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2017 by Tim Bryce. All rights reserved.

Also read Tim’s columns in the THE HUFFINGTON POST

NEXT UP:  IT IS TIME FOR THE REPUBLICANS TO FLEX THEIR MUSCLES – No more excuses; let’s roll!

LAST TIME:  MY TRIP TO THE GYM  – Things have changed over the years.

Listen to Tim on News Talk Florida (WWBA 820 AM), WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube. Click for TIM’S LIBRARY OF AUDIO CLIPS.

 

Advertisements

Posted in Business, Management, Project Management | Tagged: , , , , , | 2 Comments »

THE TRUTH ABOUT PROJECT MANAGEMENT PACKAGES

Posted by Tim Bryce on February 17, 2014

BRYCE ON MANAGEMENT

– Do they truly support project management or are they glorified punch clocks?

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

I was recently researching project management software for a client. Such software is certainly not new and can be traced back to their origins in the 1960’s with mainframe based packages. Some of the earliest applications of computers in the 1950’s were for such purposes, particularly estimating and scheduling. Nonetheless, I was looking for a PC based package that could also be implemented on smart phones, and geared to reporting an employee’s time. Frankly, I was disappointed with what I found.

I looked at dozens of packages, some free, others for a price; some were PC based, others were “cloud” based, and some were implemented over the Internet. The graphical input was easy on the eyes, but virtually none could implement what I was looking for, regardless of how well they were evaluated by software researchers. Frankly, I think they were looking at the wrong features. Instead of determining their suitability for project management, they only consider the programming, and by doing so, they have missed the boat.

The biggest problem I saw was they all supported the concept of “Man Hours,” which has long been considered a fallacious concept in project management circles. “Man Hours” is nothing more than “Elapsed Time” which doesn’t consider how time is utilized, for example, real work (Direct time) versus interferences (Indirect time). The differences are important. Since Direct time represents worker effort, it should be up to the worker to estimate and control. Indirect time keeps the worker away from his/her assignments and, as such, is up to the manager to control. The analysis of time in this regard is considered an “Availability Rate” matching the Indirect time against the total available time. Office workers typically have a rate of 70% (approximately 5.6 Direct hours in a business day), and construction workers typically have a rate of 20% (approximately two direct hours in a day). By analyzing time this way, more realistic project estimates and schedules can be calculated. As an aside, in no way should Availability Rate be considered a measure of productivity or efficiency; it is nothing more than an analysis of the use of time.

This concept originated from the construction industry back in the 1950’s. As simple and effective as it is, virtually none of the software products I studied took this into consideration, consequently they deal only in “Man Hours” and I suspect their customer’s ability to complete project assignments on time is weak. Further, by not distinguishing the differences between Direct and Indirect, it is likely their customers are micromanaging their workers. In other words, workers are managed top-down, not bottom-up where worker input is used to formulate estimates and schedules.

I also observed some of the packages clung to the concept of “percent complete” for a given task, another fallacious concept. Instead of asking workers the amount of time remaining on a task, they are asked to input the duration of the task thus far. As history shows us, even if a task is 99% complete, the last one percent can seemingly take an eternity. For more information on this, see “Estimate to Do versus Percent Complete.”

Again, all of the project management packages I researched looked slick, but virtually none could solve true project management problems. As such, they were nothing but glorified punch clocks. I find it rather ironic that despite the advances we have made in computing, perhaps the best approach to project management is a paper based solution. I guess I’ll just have to keep looking.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  THE MYTH OF EQUAL PAY – In capitalism, there is no such thing; it’s what the market bears.

LAST TIME:  WHAT’S IN A NAME: TOILETS  – 15 interpretations for the same thing.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern), KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific), and KGAB-AM (650) of Cheyenne, Wyoming. Or tune-in to Tim’s channel on YouTube.

Posted in Management, Project Management, Software, Technology | Tagged: , , , , | 4 Comments »

“BRYCE’S LAWS” MINI-POSTERS ON PROJECT MANAGEMENT AND SYSTEMS

Posted by Tim Bryce on October 9, 2012

New “Bryce’s Laws” Mini-Posters for Project Management and Information Systems have been introduced. The popular “Bryce’s Laws” include axioms for a variety of management and technical subjects, not to mention life in general. This particular collection includes ideas pertaining to Project Management (“Manage from the bottom up; not just from the top down; this creates personal commitment and accountability”) and Information Systems (“An information system is a product that can be engineered and manufactured like any other product.”) The Mini-Posters are thought provoking and good conversation starters.

Click on image to download
BRYCE’S LAWS ON
PROJECT MANAGEMENT

Click on image to download.

Click on image to download
BRYCE’S LAWS ON
INFORMATION SYSTEMS

Click on image to download.

ALSO AVAILABLE:

BRYCE’S LAWS ON: LIFE, and MANAGEMENT.

Posters courtesy of M& JB Investment Company, Palm Harbor, Florida.

Posted in Business, Management, Project Management, Systems, Technology | Tagged: , , , , | 1 Comment »

WHY PROJECT MANAGEMENT FAILS

Posted by Tim Bryce on May 12, 2010

In all of my travels, I often run into companies who ask the same question, “Why can’t we get our act together? Why does Project Management routinely fail in our company?”

I don’t believe a company’s overall problems in Project Management can be attributed to a specific tool or technique (although some certainly do not help matters). Instead, I believe it is based on how important a company considers Project Management to be. If they believe it to be a vital part of the company’s overall performance, it will be more successful than a company who considers it irrelevant. In other words, I view Project Management as an integral part of the corporate culture.

Let’s consider the indicators of how a company values Project Management:

* LACK OF KNOWLEDGE – employees simply lack the basic knowledge of the mechanics of Project Management. I don’t run into too many companies anymore with a total absence of knowledge in this regard. The conceptual foundation of Project Management has been around for a number of years. There is a multitude of training programs in Project Management, both at the college and commercial level. There are also several discussion groups on the Internet and professional associations dealing with this subject (e.g., the Project Management Institute of Newtown Square, PA). Hiring or contracting people with absolutely no knowledge of basic Project Management concepts is becoming a rarity.

* LACK OF ORGANIZATIONAL POLICY – the company has not adopted a formal policy for managing projects. Consequently, informal and inconsistent approaches to project management are used with mixed results. This is a much more common occurrence than finding a company devoid of knowledge in Project Management.

* LACK OF ENFORCEMENT OF POLICY AND PROCEDURES – even though a policy has been established, it is not enforced. As a result, inconsistent results emerge. If a standard and consistent approach to Project Management is devised by a company, it must be routinely policed in order to assure accuracy and uniform results. It is one thing to enact legislation, quite another to enforce it.

* LACK OF CONSIDERATION FOR THE MAGNITUDE AND COMPLEXITIES OF PROJECT MANAGEMENT AND ATTACK IT IN PIECE MEAL – People seem to naturally underestimate the magnitude of project management. For example, project planning involves defining work breakdown structures and dependencies which is a precursor to estimating, scheduling, reporting and control; estimating is a prerequisite to scheduling; time reporting impacts project estimates and schedules; resource allocation is based on availability of qualified people (skills inventory) and current project schedules; etc. There is an overwhelming number of software packages on the market attacking various aspects of Project Management, but very few addressing it as an integrated whole.

It must be remembered that project management is first and foremost a philosophy of management, not an elaborate set of tools and techniques, nor is it an administrative function. Rather, it is concerned with managing human beings towards the accomplishment of work (it is a “people management” function). As such, project management will only be as effective as the people who use it.

Ultimately, project management represents DISCIPLINE, ORGANIZATION, and ACCOUNTABILITY; which are three areas people seem to have a natural aversion to these days.

LET’S CONSIDER ALL THREE

DISCIPLINE – In the western world, people tend to resist discipline because some believe it inhibits creativity and personal freedom. As a result, teamwork is often sacrificed in favor of rugged individualism.

ORGANIZATION – Pursuant to discipline is the problem of organization. Again, in the western world, people prefer to maintain their own identity and organize themselves to meet their needs as opposed to the needs of the organization. There are also those who claim, “A cluttered desk is the sign of a brilliant mind.” Hogwash. In contrast, I am a believer of the Navy’s regimen whereby you either work on something, file it, or throw it away. This forces people to get organized. If we need more files, let’s get them. A cluttered desk is a sign of a disorganized person. Shape up, or ship out.

ACCOUNTABILITY is an area people tend to rebel against the most. The approach to project management, as advocated by “PRIDE,” ultimately represents visibility and responsibility to produce according to plan. Unfortunately, some people shun commitments and, instead, prefer to hide their activity, thereby they cannot be measured and evaluated. This is typically the reaction of people who are insecure. People who are confident in their abilities have no problem with the accountability issue.

REACTIVE VS. ACTIVE MANAGEMENT

The old adage, “If you do not make the decision, the decision will be made for you,” is valid. This also sums up the difference between an active and a reactive manager. True Project Management requires an “active” manager, not “reactive.” The active manager takes care of the problems before they happen. They plan on the future. The reactive manager deals with yesterday and waits until problems occur, then tries to take care of them. Today, more and more IT organizations find themselves in a constant “firefighting” mode of operation. Why? Because of a “reactive” management style. The “reactive” manager never seems to get ahead, yet probably enjoys the highest visibility in the company. As an aside, beware of your “firefighters,” they are probably your chief arsonists.

Managers don’t wait for things to happen, they make things happen.

HOW MUCH PROJECT MANAGEMENT IS NECESSARY?

Can the philosophies of project management be adopted and implemented by a single group of people for a single project? Yes. A department or division? Certainly. The entire company? Definitely. In fact, as the scope grows, communications improves and the philosophy is more consistently applied.

The scope of project management affects many people:

* The individual worker will prepare estimates and schedules, perform project work, and report on activities.

* The project manager will plan and direct the use of resources on projects, and solve problems.

* Department managers will administer resources and control projects within an area.

* Executive management will establish project priorities and monitor project progress.

Obviously, project management should not be restricted to a handful of people or projects. Dozens of projects may be active at any one time, involving hundreds of workers across departmental boundaries. Synchronization of the work effort is required to maximize effect and minimize confusion. Project management, therefore, should be viewed as a corporate philosophy as opposed to a technique used by a select few. Only when a standard and consistent approach to Project Management is adopted by a company will it become an integral part of the corporate culture. We will then hear less about why Project Management fails, and more of how the company is prospering.

“It is one thing to enact legislation, quite another to enforce it.”
– Bryce’s Law

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm

Copyright © 2010 by Tim Bryce. All rights reserved.

Posted in Management | Tagged: , , , , , | Leave a Comment »

A TALE OF TWO PROJECTS

Posted by Tim Bryce on April 14, 2010

The following is a true story; a vintage “Dilbertism.” Because of this, the names have been changed to protect the innocent (as well as the guilty). Interestingly, I do not believe this story to be unique and similar stories can be found in countless IT shops around the world.

Our story begins just a couple of years ago in a large manufacturing company in the American Midwest. At the time, the company was interested in replacing two aging, yet important, systems; an Accounts Payable System (“AP”) and an Accounts Receivable System (“AR”). The IT Director selected two of his most seasoned veterans to manage the projects, we’ll call them “Steve” and “Bob.” Both project managers were charged with their responsibilities on the same day: Steve to build the AP system, and Bob to build the AR system. Both were given approximately the same amount of human and machine resources to accomplish the work.

Steve was a very organized and disciplined manager. He found it essential to organize and train his staff upfront so everyone understood the development process, the deliverables to be produced, and their assigned responsibilities. Recognizing the large scope of his project, Steve felt it important to methodically attack his system and meticulously worked out a plan and schedule to implement it. In Phase 1 he spent what appeared to be an inordinate amount of time studying the business problem, specifying information requirements, and developing a rough design of the system solution. Steve’s people actively participated in this early phase and thought the problem through carefully before proceeding with the project. Following the Phase 1, Steve’s team finalized details of the overall AP system architecture, and divided his group into teams to tackle the various sub-systems in parallel. To complement this effort, his data base people oversaw the logical data base design to accommodate the needs of the whole system, not just any one portion of it.

Steve also recruited the support of the AP Department and had key personnel from this area participate in the development of the system. The input from these users was vital not only in Phase 1, but also in succeeding phases where the business processes were designed.

By concentrating on the overall system architecture and then by gradually refining the design over succeeding phases, the Software Engineers were given detailed specifications which were easy to follow and implement. Consequently, the programming phases went smoothly, including testing.

The core sub-systems satisfying the operational needs of AP were on schedule and being installed with great support from the user community.

While Steve’s project was coming along smoothly, Bob was facing chaos with the AR system. Instead of studying the problem upfront, Bob’s group began by building a core data base. Shortly thereafter he set his programmers to work building some basic input screens and some rather simple outputs. In no time, Bob had something to demonstrate to the user community (and his boss) to prove progress was indeed being made.

But Bob’s group had not done their homework. The AR community was not consulted and requirements were not defined. As a result, programmers were left second-guessing what the users really needed which started a long round of “cut-and-fitting” the code. Further, the integrity of the data base came into question. False assumptions were made about calculated data elements which cascaded throughout the program code. In addition, data validation rules were not established. This forced the programmers to invent their own rules and formulas for calculations in each of their programs which led to data redundancy issues and even bigger headaches for the development staff. As users were given glimpses of the programs by Bob, data integrity issues became an issue and the users didn’t trust the information being produced by the system (e.g., calculations were computed differently by the various programs). Bob’s group touted the AR system as “state-of-the-art,” but the users were not convinced it was reliable or intuitive to use.

All of this lead to a redesign of the data base and programs, not just once but several times. Consequently, the project schedule started to slip and costs exceeded budget. To overcome this problem, Bob and his staff worked overtime to play catch-up with the schedule (which he never realized). Regardless, the IT Director began to take notice of the long hours Bob and his team were putting into the project and complimented them on their dedication.

Bob finally delivered a portion of the project to the AR department, but in testing it the users found it fraught with errors. To overcome this problem, Bob’s group was ever ready to jump in and modify the code as required. Even though the users found the programs buggy, they commended Bob for how quickly his group would be able to fix them.

The difference between Steve and Bob’s groups were like night and day. While Bob operated under a “helter-skelter” mode of operation, Steve’s group operated quietly and began to deliver the system on time and within budget, much to the user department’s satisfaction.

Steve understood the enormity of the system and its importance to the company, and, as such, took the time to organize and train his group accordingly. Bob also understood the importance of his application but took the tact of producing something management and the user community could “touch and feel” thereby demonstrating something was happening in his department, right or wrong. Further, his SWAT team approach to putting out fires made him a favorite with corporate management. As a result, Bob enjoyed a high profile in the company while Steve was a relative unknown.

Unfortunately, Bob’s project ran amok, unbearably so. Recognizing he had to do something radical in order to get Bob’s project back on track, the IT Director made an unusual move; he swapped Steve and Bob as project managers. Steve was charged with cleaning up Bob’s mess, and Bob was charged with finishing Steve’s project. Offhand it sounded like a shrewd move. Steve had proven to the IT Director he could get things done, regardless of the application size. And the IT Director figured Bob could simply close-out the AP project. The IT Director figured wrong. While Steve started the arduous task of bringing organization and discipline to the AR system, Bob quickly dismantled Steve’s organization and brought chaos to the AP system. This did not sit well with a lot of people, particularly Steve’s former project team who felt they had grasped defeat from the jaws of victory. Steve was also growing disenchanted as he had almost completed one system and was now charged with cleaning up his predecessor’s mess. To add insult to injury, because of Bob’s high profile status, he was given an increase in pay and job promotion, and Steve didn’t receive likewise.

Steve got the AR system back on track and finally implemented it much to the satisfaction of all concerned. Bob lost control of the AP system almost immediately and it spun out of control until Steve was finally called back in to finish it. Not knowing what to do with high-profile Bob, the IT Director made the classic move of promoting Bob and transferring him to another area where he could do no harm.

LESSONS LEARNED

Is there a happy ending to this true story? Not for Steve. Although he cleaned up the mess and ultimately managed both projects to a successful conclusion, he became disenchanted with how he had been treated by the company. Subsequently, he left and started his own consulting firm who was ultimately hired by his old company to develop new systems (at substantially higher rates). As for Bob, he enjoyed the perks and pay resulting from his new position for quite some time. Eventually, he got the hint and moved on to another company where he made a similar name for himself.

Although Bob was a fine example of the “Peter Principle” (rising above your level of competence) he recognized results were not necessary on the road to success but rather, image was everything. He learned early on that “the squeaky wheel gets the oil.”

As I mentioned at the outset, this is not a random incident, but one that could probably be told by a multitude of corporations who have “promoted the guilty, and prosecuted the innocent.”

Have you got a similar story? Please do not hesitate to send them to me.

“Beware of your firefighters; they are probably your chief arsonists.”
– Bryce’s Law

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm

Copyright © 2010 by Tim Bryce. All rights reserved.

Posted in Business, Management | Tagged: , , , | Leave a Comment »

 
%d bloggers like this: