Professional Consulting Services

On this page, we hope to enlighten you on the basic concepts of project management and related methodologies.

We are excited about our development of a full-life-cycle project management methodology program that we will release early next year 2010. The program is a series of courses that end with a methodology expert, a robust methodology that spans numerous methodology concepts and a series of pc based and on-line tools capable of managing and reporting on local, national or global projects.This is an immense project since it looks at many of the more successful methodologies and provides insight on when to use which one.A weakness of many methodologies is in the application development itself or in the selection and sizing of hardware, software and networks.We will be addressing all phases of project development to provide an end to end process that puts an end to which methodology should I use.

There will be follow up courses and modules to add expertise in various business concepts. It is an undertaking that has been in the planning process for a couple of years; it is an exciting project that we hope you will like.

Many processes in business interact with computers whether it is customer orders, help desk support, inventory control, budget analysis or shipping strategies, most employees that have a desk have a computer. For that reason projects of any real size include the incorporation of computers. Indeed, if we are considering administrative procedures of one type or another, computers can be a major tool for performance enhancement.

There is an array of methodologies out there supporting the complete project end-to-end or at least they propose to do so.

Waterfall is one technique that assumes you complete one step before starting the next, when building a house the basement comes first followed by the shell. However, some projects may gain from experience. This might be true of a nation-wide project where the rollout is not based on the same phase for each location, but one location being completed after the other. For project teams with less experience continual development testing and re-work may be needed. For the mature project teams good forethought and front end work creates an organizational flow. A good design with test requirements well developed and a global set of variables can allow the project to branch into parallel processes. Once the design is complete and it screen shots were part of the design process training material can be created while programming is under way along with data mining and data base development. Testers can be orchestrating what needs testing when and can test not just the finished product, but intermediates steps to ensure compatibility with the design. Waterfall spends a lot of time up front to ensure further steps do not need rework and that their are few if any requirement changes.

The Sahimi model is basically the Waterfall model with the major exception that it allows for overlapping phases. And as you can see in the paragraph above there are plenty of over lapping events, so it is not a pure Waterfall process. But wait a minute I included proto-type screens in my Waterfall model above, if they are programmed screens that is not a Waterfall it is a Spiral process model. However, if they screen are non-function, built as a Microsoft PowerPoint graphic they are part of the Waterfall process.

The Chaos model takes up where the Spiral model leaves off with considerations for writing program modules rather than the whole program. It addresses more of the software development from a high level. Build a piece of code and make sure it works, then build the next piece. That is a great concept, the testing and developing modules, but it is asynchronous. Well it appears that if you take a methodology at it emphatic definition there is room for discussion as to exactly how a project should flow. From Wikipidea we see a long list of methodologies:

Agile software development
Agile Unified Process (AUP)
Behavior Driven Development (BDD)
Big Design Up Front (BDUF)
Brooks’s law
Build It Fast And Fix It Later (BIF+FIL)
Cathedral and the Bazaar
Code and fix
Constructionist design methodology (CDM)
Cowboy coding
Crystal Clear
Design-driven development (D3)
Don’t repeat yourself (DRY) or Once and Only Once (OAOO)
Dynamic Systems Development Method (DSDM)
Extreme Programming (XP)
Feature Driven Development
Hollywood Principle
Iterative and incremental development
JAD (Joint Application Development)
Kaizen
KISS principle (Keep It Simple, Stupid)
Lean software development
Microsoft Solutions Framework (MSF)
Model-driven architecture (MDA)
Open source
Open Unified Process
Project Cycle Optimisation (PCO)
Quick-and-dirty
Rational Unified Process (RUP)
Scrum
Separation of concerns (SoC)
Service-oriented modeling
Software Craftsmanship
Software System Safety
Spiral model
Test-driven development (TDD)
Unified Process (UP)
V-Model
Waterfall model
Wheel and spoke model
Worse is better (New Jersey style or MIT approach)
You Ain’t Gonna Need It (YAGNI)

Some sound silly and maybe in some ways they are, but most are nothing more that derivations on the best approach to working through a process. Rapid Application Development was a response to the delays often seen in the longer Waterfall, Spiral and Agile approaches. These methodologies where popping up in trade journals almost weekly as the next person took their turn in the lime light. Some of the articles were driven by staunch advocates for one process or another where common sense was overruled by the rules of the methodology.  JAD (Joint Application Development) may have been one of the most annoying. A key set of the project team work on the project and “guests” can attend the meeting, but according to strict rules could not interfere, even if they had the answer.  I gritted my teeth a lot and found the whole game ridiculous, but if interference through organization bickering was an issue it may have a place.

The other problem people ran into ways arguments over which to use when. On an enterprise level project you had better have a good handle on a strong methodology even if it is your own. However, these big methodologies require documentation, assigned members and tracking systems. Complaints I heard that made little sense to me was how can you apply such an expense to a simple 25 line program it is too expensive. Duh! These methodologies were never created for the one day fixes, they were created to control and ensure success on enterprise level projects.

ISO-9000 and Six-Sigma suggest formal approaches to documentation and processes that ensure repeatable behaviors. Nothing wrong with that and if you are a serious programming shop it is excellent. If you are a stand alone programmer in a fast past environment the first thing to go out the window is documentation and organizational controls. You are flying and free to code on the wind. That is until something goes wrong. Or you leave the company. There is some changes you can figure our the lengthy code and where it is corrupted, but it is near impossible for someone following in your foot steps. If code becomes complicated enough it can actually turn back on itself undoing what is done elsewhere and then re-doing what was undone. variables can have different names and yet are the exact same value because a data dictionary was not maintained. Think it does not happen, look to any legacy system. Then for more corruption consider the datanames of the pc based applications hanging off the legacy systems where data may be passing from mainframe, to mini to pc.

I believe methodologies and structure well documented processes, programs and data are indeed good for the development process and down stream maintenance. Good analysis on the front end also ensures the new programs meet the clients needs and are not the IT organizations perceptions of what is needed. Further programs developed under solid business analysis shoudl be looking at the future at least 5 year out and what is needed to compete in the open market. Do these features meet then needs of the customer, can order prcessing be done faster, will customers be satisified, will the process attract new customers. The ATM at banks is a good example of taking the teller ouside and then eliminating the teller for simple transactions. ATMs are everywhere and allow us to bank 7 days a week 24 hours a day. For the bank it lowers the number of employees standing at the counter all day waiting for someone to walk in the bank.

Which methodology is right for you and your company is much like buying a pair of shoes. Some appreciate the straight laced Wing Tip and others go for the more casual loafer or the dashing athletic shoe. They all provide support, but serve best in specific applications. If you are a one methodology wonder, maybe it is time to look around at what elese it out their and why they were created. You may stay with your current model or you may adapt the rigor with which you apply it. Maybe you see the methodologies as the painters palette where you can pick and choose moving from one methodology to the next to complete your work of art. No methodology is perfect, but they are far better than no methodology at all.

In our on-going project we hope to bring out the best in each practice and dispel notions that can lead to confusion. We will provide project management details that will keep your project on track and create positive outcomes. To enhance your understanding we will even provide experiences from some of our projects, after all experience is what helps build the expert.