IT Projects Success - Principle #11: Partition large projects into 3 month phases

Continued from:

http://blogs.itworldcanada.com/insights/…

(Want to see more? head over to http://bit.ly/Ypycy )

11. Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

I was lucky to learn this early in the 90’s as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance. What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, “A plan is only good until the battle is joined.” After that, one must adapt to the changes that will always come.

My own experience was on a large project that was broken into a dozen pieces, which were planned separately to a target 18 months away, at which point I was asked to integrate them into one plan while resolving resource conflicts. First thing, we found was that MS Project of that time crashed when you reached around a thousand tasks.

So, it was about this time that some IBM PM consultants were brought on to sort out this mess, and where I first heard the above principle. Yes, you need a plan to get started and to control a project over time. You can even sketch out a plan out over many months to see and communicate the big picture; but, do not commit to any target date over 3 months away, odds are you will miss it. This also means you should do the detailed planning only to the next target date, meaning the full WBS and resource assignment. (At the other end of the detail level, the IBMers also recommended that the shortest task in your WBS should be 2 weeks, no less, otherwise you are micro-managing.)

Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any 3 month period will be manageable, much more than over the whole project.

There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every 3 months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in 3 month quarter cycles anyway, IT should too.

IT Projects Success - Principle #10: Models are better than text.

10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it.

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

(see more at http://stores.lulu.com/dwwright99 )

IT Projects Success - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave.

9. Leave a record of what you have done, so the project will not miss you if you leave.

If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in “quick and dirty” projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in #8 above, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.

Last Chance to Participate - Business Analysis Benchmark

This is your last chance to participate in the 2009 Business Analysis Benchmark study - and access your copy of last year's research. Last year, this research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year's theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CPC1M/61635542

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-20/CPC2Q/61635542

IT Projects Success - Principle #8: It’s the Deliverable (that matters), not the Task.

8. It’s the Deliverable (that matters), not the Task.


The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.


This means that the project work will be divided into many tasks, sub-tasks, etc. . . . Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.


What this can lead to is an over-emphasis on the how of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90% done for weeks, or the infamous ‘analysis paralysis’ where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.

Can IBM automate decisions? Sure, it's already happening.

News post: Algorithms everywhere: Can IBM automate business decisions?

http://blogs.zdnet.com/BTL/?p=16345&tag=nl.e019

see “Smart (Enough) Systems” http://www.smartenoughsystems.com/ by James Taylor.

This is not about automating decisions made by people, it is about automating decisions that don’t need people. Dig deeper, and this is about Business Rules. In situations where all responses to a question can be defined depending on data about the situation, having people pick an answer is a waste. Biggest example? Credit Checks and your Credit Score, and ‘deciding’ to approve a request for credit. This is being done thousands/millions/whatever times per hour/day, and there not enough people available to do this.

Why do you think IBM bought iLog? Advanced companies already do this. Insurance underwriting is another big domain.

And this is never going to be about Artificial Intelligence. Smarter systems are made of the same stuff as ‘dumb’ systems, they just know more, enough to make a decision based on facts. If the facts aren’t available, the system is not going to ‘think’ or ‘reason’ its way to a decision, its just going to ask for the facts, please.

AS-IS versus TO-BE

Have not seen a great methodology debate (without the word 'agile') for ages. Here is one over at Modern Analyst, with my comment already added: http://bit.ly/WNLN

IT Projects Success - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester

7. One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with the specialization of Principle #6 to form the strong basis for the Cascade effect covered in Principle #13. … so stay tuned.

2009 Business Analysis Benchmark study

IAG Consulting ( www.iag.biz ) is conducting its 2009 Business Analysis Benchmark study. I invite everyone to participate, as last year’s research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year’s theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CI49E/56513172

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-01/CI4AI/56513172

IT Projects Success Principles 3 and 4

IT Projects Success - Principle #3: Use Architecture to describe the business, before and after projects.

Continued from:

http://blogs.itworldcanada.com/insights/…

3. Use Architecture to describe the business, before and after projects.

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.

Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.

For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.

It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT. Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.

The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman.

(see www.zifa.com for details)

He devised the illustrated matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems.

The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.

Last two points on Zachman:

- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions. Keep this in mind for Principle #10.

- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.

---------------------------------------------------------------------------------------------

IT Projects Success - Principle #4: Pick the right project(s) for the business.

Continued from:

http://blogs.itworldcanada.com/insights/2009/03/20/it-projects-success-principle-3-use-architecture-to-describe-the-business-before-and-after-projects/

4. Pick the right project(s) for the business.

At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?

No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one common, higher manager has to step in and decide who gets what; and this is often the first time the higher manager has even heard about the projects.

I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before?. The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as ‘Project Governance’.

So, how do you pick the ‘right’ IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a ‘gating’ process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.