Business Analyst Blogs & Systems Analyst Blogs

Author:	David Wright	Created:	11/14/2007 4:58 PM
Focussed on my recent publication "Cascade", which is a bit about being a BA, and lot about succeeding in a typical company.

Memories of IT

By David Wright on 6/19/2008 8:52 AM

I am now lucky enough to be working at a consulting company with a great group of experienced people, and we do share some great "war stories", and it made me think that I do have my share of experiences that, if written down, some small number of people may find interesting. Seems to me a blog is great for that.

I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.

But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.

Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer...

Cascade - that's all 13 Principles of mine: do you have any? win a free copy of my book.

By David Wright on 6/17/2008 4:06 PM

Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at http://www.lulu.com/content/2088656 .

In fact, if (and its a big if) I get a number of suggestions, I will judge which one to be the 'best' of the bunch; winner gets a free copy of the book.

And to get things going, a free copy of the book also goes to the first person to submit a suggestion, so be quick!

David W. Wright

Cascade Day 15 - Principle #13: Use Architecture to Manage and Integrate the Deliverables

By David Wright on 6/13/2008 2:47 PM

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system. This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled. In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business...

Cascade Day 14 - Principle #12: Parcel work into two-week periods

By David Wright on 6/9/2008 3:01 PM

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

Cascade Day 13 - Principle #11: Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change

By David Wright on 6/5/2008 11:31 AM

#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...

Cascade Day 12 - Principle #10: Models are better than text

By David Wright on 6/2/2008 9:08 PM

#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...

Cascade Day 11 - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave

By David Wright on 5/29/2008 9:57 AM

#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 principle #8, 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.

Cascade Day 10 - Principle #8: It’s the Deliverable (that matters), not the Task

By David Wright on 5/28/2008 9:46 AM

#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....

Cascade Day 9 - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

By David Wright on 5/27/2008 9:29 AM

#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 the last principle to come. I will be using the most common ‘role titles’ of analyst, designer, developer, and tester for the remainder of these...

Cascade Day 8 - Principle #6 - Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

By David Wright on 5/22/2008 9:53 PM

This principle supports #5. With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time performing the other roles than an appropriate specialist would, and is distracted from being productive in their primary role. At any time, and perhaps more so currently, there will be debates about which is better, a generalist or a specialist. I will agree that a strong, experienced generalist who can cover a wide number of tasks is the best resource you can have. However, these people are rare, and the odds of having even one such person in your average IT department are low . So, make sure that your staff is doing what they do best as much as possible as often as possible. ...

Cascade Day 7 - Principle #5 -Once a project is started, finish it.

By David Wright on 5/22/2008 12:25 PM

Even with a good process to pick the right projects to execute, there will be a strong if unrecognized tendency to initiate too many projects at once, or initiate more projects before any already underway have been completed. This goes back to the average senior manager’s split view that most IT spending is a waste, except for their own projects. Given several senior managers in an organization expressing these views, a natural reaction is to have at least one project underway for each manager; if most of the IT efforts are applied to projects for only a few managers, the rest will complain or start looking for other options.

However, trying to run too many projects at once ends up pleasing no one, as no project makes any noticeable enough progress to be seen as a success, so the result is that no one is happy with IT’s performance.

So, projects have to be run such that at least one is completing within each reporting period; this would be quarterly in most companies. In large IT shops with dozens...

Cascade Day 7 - Principle #4 - Pick the right project(s) for the business

By David Wright on 5/21/2008 11:03 AM

Principle #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...

Cascade - Day 6 - Principle #3: Use Architecture to describe the business, before and after projects.

By David Wright on 5/20/2008 9:54 AM

Principle #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.

...

Cascade - Day 5 - Principle #2: Projects change the business, so know the overall business first

By David Wright on 5/16/2008 10:38 AM

A never-ending discussion in IT circles is about how much IT staff need to know about the business that the information systems are supporting...

Cascade - Day 4 - Principle # 1: There is always more work to be done than people to do it.

By David Wright on 5/15/2008 10:25 AM

Let’s look briefly at what each principle means or implies; which will serve as introductions to subsequent posts that will cover the principles in more detail. #1. There is always more work to be done than people to do it.

Cascade - Day 3 - Principles

By David Wright on 5/14/2008 1:54 PM

...like most inventors of new principles or practices, I have come up with an overall name to encompass them, for now and as they evolve. It is: Cascade – Better practices for effective delivery of information systems in a multi-project environment. ©

Join the Premier Community for
Business Analysts, Business Process Professionals,
Systems Analysts, Data Analysts, and more…

Blogs for Business Analysts and Systems Analysts