Using requirements tool remotely.

I have just realized that my last post here was back in May of last year... probably due to a combination of being busy with work I am enjoying, and not having any sudden urges to share something on the overall topic of business analysis, or IT in general.

So what's keeping me busy? an on-going project for a new system that has multiple stakeholders spread across the United States. What this means is that the project is using a requirements tool accessible over the net, so we have a meeting or two with stakeholders gathered in one place, followed by follow-up work done remotely using the tool, email and skype. That meant a lot less travel, and my "commute" was to walk down the upstairs hall in my house.

The interesting thing is the remote use of the tool. Maybe only a few years ago, being able to do this would have been seen as an amazing new capability; now we get annoyed if response time is less than immediate. It would seem that user expectations are still zooming ahead of tech capability.

Cascade #7 - Knowing too much about your business people's business...

How much does IT need to know about the specific way their employer conducts business when competing in their industry? Again from experience, I suggest that very little or no such knowledge is needed going into a project. The cliché that “a little knowledge is a dangerous thing” applies here. If IT people know too much about the current business, they may be unconsciously constrained when devising new IT solutions by ‘the way things have always been done here.’ In extreme cases, this can lead to an IT staffer having the delusional belief that they know more about the business than the systems users and their management.



Do not fall victim to this belief. IT is about underlying hardware and infrastructure, and the information systems that run on them. The systems’ users and their management --- supported by all the strategies, policies, procedures and rules that define and control the business --- will know the specifics of their business better than IT; their jobs depend on it.



This is not to imply that all business users & management are omniscient, or that all businesses operate without duplications or errors, or that there are not things the business doesn’t know yet. In fact, effective use of IT can address many such issues in the operation of a business, but IT and IT people do this in support of the business; IT does not define the business.



So, know your business in order to support your business.

Comments, anyone?

David Wright
www.twitter.com/dwwright99

Cascade #6 - Projects change the business, so know the overall business first.

Projects change the business, so know the overall business first.



A never-ending discussion in IT circles is about how much IT staffers need to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory.



Is detailed industry knowledge and experience absolutely necessary for an IT job? No.



Can an IT staffer be effective with absolutely no knowledge of their employer’s industry? No.



As in many situations like this, the ‘Yes’ answer lies somewhere between the two extremes. Like a pendulum, the level of industry knowledge will vary across this spectrum, based on the specific organization, and by the particular IT role; e.g. Analysts need to know more than Programmers, and it justifiably argued that Testers need to know even more than Analysts.



So, some industry knowledge is required. I suggest from experience, however. that several week’s research on an industry is equivalent to several year’s work experience, as much of a person’s experience is rendered out-of-date by industry changes, or is too specific to the company they worked at. This is truer today than ever, as the ubiquitous Web makes information about almost anything available with a text string and few mouse clicks. (I especially like to look at vendors who offer packages that address any project I am working on, even for in-house development, it's a good way to see what the wider industry has been asking for.)



As a result, IT needs to know something about the industry going into a project, and the willingness to learn more as a project progresses.

Readers: Do you agree with me on this? I have had many conversations over the years with people who disagree; I have also had some business people say they get frustrated with "why does it take IT so long to learn my business?" What do your business people think about this?


Next in Cascade #7 - Knowing too much...

David Wright
www.twitter.com/dwwright99

Cascade #5 - There is always more work to be done than people to do it.

There is always more work to be done than people to do it.

This principle summarizes the reality of virtually all organizations and activities, not just Information Systems delivery. It implies that a group within an organization charged with delivery of end results will a have a back-log of work not yet done. The existence of such a back-log is in itself not a problem, it reflects the desire of an organization to solve new problems and proactively improve itself; the problem arises when it grows perceptively in size from management’s perspective, and the length of time a change item sits on the back-log increases such that it can be measured in numbers of months or years.

So, we must accept that there will be a backlog; fully eliminating it would mean that the delivery group (like IT) becomes redundant, or that the overall organization has stagnated. What must be done is to embrace the back-log; it is IT’s input material and should be managed as such.

Question for Readers: How big is your backlog? Is it considered a problem? How do you select what to pick from the backlog to do next?

David Wright

www.about.me/dwwright99

Cascade #4 - Principles for improving IT Projects

Like you, I have read my fair share of IT books, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems; the reverse is to document the new approach/method first and then describe what problems it fixes.



I am using a mixture of the two, in the context of a set of Principles that will put all the content of this book in context. This is not an original idea, I must admit, as many manifestos and proclamations have been used to introduce new ways of things; the Agile Manifesto is well known (http://agilemanifesto.org/ ) andI am a particular fan of the Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm). These and others like them lay out the basic reasons for their existence and the value they provide.



So what are these new IT principles I propose?



1 -There is always more work to be done than people to do it.


2 -Projects change the business, so know the overall business first.


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


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


5 -Once a project is started, finish it.


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


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


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


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


10 -Models are better than text.


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


12 -Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks ( 2 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.


13 -Given many medium to small software Deliverables, use architecture to manage and integrate the Deliverables into a complete system.


In Cascade #5 we will start looking at each Principle.

Cascade #3 - What can you do about all your IT Projects?

So, what can you do?



You have to deliver on all those change requests, and finish those current projects so you can start new ones (there will always be new ones); this means accepting the things you can’t change and changing the things you can.



What can’t you change right now?

-The installed base of legacy systems.

-The backlog of change requests and bugs (even if you do manage to deal with a lot of these things, there will be new ones come along to take their place; that is job security).

-Senior management’s’ conflicting priorities for IT.



All of this is pent-up like rising waters behind a dam ready to burst. Something has to change, but you can’t just blow a hole in the dam, the result would be chaos.



So, what can you change (or at least start to change)?

-The structuring and management of the IT projects.

-Overall management of staff by skills/specialties.

-Effective allocation of staff to the projects.



What follows in the rest of this book-to-be is my prescription for this change, supported by some war stories, lessons learned, and lots of ideas to try. Every company has some unique aspects, so maybe not everything in this book will work for everyone, but I hope to give you enough ideas that some will work. My own fervent belief is that visible success with IT projects now may lead to softening/improvement of the things you can’t change right now.



I also really want to get your comments on what you think of the ideas I present, and I want to hear about what you do to deal with running multiple projects.





David Wright

www.about.me/dwwright99

Cascade #2 - "a project does not exist in a vacuum"

From previous post
Projects are hard. Many years of doing projects, often unsuccessfully, has led the IT world to focus on how to do projects successfully. Project Management has emerged as a recognized discipline, and many smart people have provided many methods and methodologies for delivering IT solutions.

That is all well and good. What I have known since early in my career is that a project does not exist in a vacuum. Change does not happen in an orderly manner, one project at a time; it rushes at your company, lots of change happening all at once. That means many projects at the same time.


Do any of the following situations ring true for your company?


-A large portfolio of installed of information systems and underlying technology is being used, some of which is decades-old.


-A large back-log of requested changes to that installed base of systems has grown over time, overlaid with a long list of problems/bugs in the systems that the business is currently ‘working around’ until they ever get fixed.


-A large number of current projects are being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.


-The projects are being executed by a group of IT staff that has remained the same size in numbers, or has been reduced, while being charged with doing more work than ever. Each person is probably assigned to many of those current projects, juggling the work and trying to determine what they should really be working on.


-An “IT Strategy” has been developed that describes in glowing terms how the above problems will be remedied by moving to some new method or tool or one enterprise system… if the budget and resources can ever be freed up from fixing and changing the current systems.


-Senior management has a split-view of IT, that most of it is a waste of time and money, except for the work each manager wants for their own department/division.


I am writing this book in order to show you that the situation described above can change, and you had better get to it because it can get changed for you by outsourcing or other drastic options available to senior management.

Readers: To me this is the main problem, how many projects can you run at the same and get something done? There are lots of methods out there that tell you how to run one project well, but without any context of competing resources and priorities. I have been reading about Kanban lately, how it works for a project or an activity by limiting Work in Progress (WIP). Can Kanban work to manage multiple projects? I will keep reading but your feedback is, as always, most welcome.

In Cascade #3: "what can you do?"