29 February 2008

3 levels of requirements

I picked this concept up from a discussion on the Yahoo Requirements Engineering Group and thought it may be interesting to you.

According to the boffins requirements have 3 levels; business, user and system. Each of them focus on a different aspect of the problem at hand. For example; business requirements are usually about defining the business problem and target outcome.

Let me quote Keither Collyer from the thread to explain it further.

"This division into three types of requirement is very common and is partof standard practice for a good many organizations. It is what Igenerally recommend with my customers. Although each of these threetypes could be divided further (and often should be), there are clearconceptual divisions between them.

They are far from being meresupplementary types.Summarizing what Gottesdiener writes (my words, not hers);

  • Business requirements describe business needs. They don't say anything directly about the system. Without business needs, there is no reason to develop the system. This is a high level definition of theproblem to be solved.
  • User requirements (or, more generally, stakeholder requirements) describe what users (and others) must get from the system in order toachieve the business needs. These are primarily about what the stakeholders will be able to achieve. This is again about the problem tobe solved, but at a more detailed level.
  • Software requirements (or, more generally, system requirements) define what the system must do in order to satisfy the stakeholder requirements.You can think of these levels as "why are we building it, what it must achieve and how it will achieve it."

In a sense, business and user requirements are both forms of stakeholder requirements. But the difference is still worth maintaining.

It is arguable that there might well be various levels of system requirement, for example, if the highest level leads to a design, then the various elements of that design (sub-systems) will have their own system requirements - but these are not a conceptually separate type of requirement, they are still about what the (sub-) system must do."

28 February 2008

Is the BA an endangered species with the growth of Agile?

First, I'm a project focused software developer, team lead, designer, architect, jack of all trades, who has been on projects that have used various methodologies over the years, including of late some agile projects.

I'm not a big blog reader, or a big blogger, but like most people I have an opinion on things, and for some reason that opinion is valued by various people I have met in my life's journey, so I have been invited to provide input into this forum from a technical perspective.

Doubtless, my blog posts will be intermittent, and possibly contentious. So this marks my debut posting for the Better Projects blog. I have been reading of late various blogs around the place (usually when hunting for other information) on the imminent demise of the role of the BA, with the growth of Agile and the perception that the role of a BA is not required in an Agile project.

From a BA community perspective there seems to be a sense of impending unquantified unease, if not one of impending doom. For the IT community, there is growing conjecture on whether the BA is really an unnecessary evil that can be dispensed with in an Agile project.

To paraphrase Mark Twain, rumours of the death of the BA is greatly exaggerated.

To understand why I'm of this opinion, I want to consider four things. What is the business? What is a BA? What is the role of a BA in an Agile project? What is the future of Agile?

What is The Business?
To generalise, the business are focused on two things:
  • Operations; which equates to staffing, training, process compliance, materials, machinery, transport logistics, supply, SLA's, demand or orders, stock levels, etc.
  • Management; the analysis of cyclical trends, identifying markets, advertising campaigns, market share, competitor analysis, capacity, contracts, etc.
For the company to be successful, management has a need for accurate statistics to be derived from their operational areas, and operations has a need for efficient, low waste production, yet retaining flexibility to meet varying levels of demand.

The Business are not necessarily good at identifying where they can improve, how to go about change, or even to identify what process' they do undertake. They often however, identify the need for change but will usually struggle to articulate what this change will look like. This is when they usually turn to the BA.

What is a Business Analyst (BA)?
I will probably be telling the readership of Better Projects how to suck eggs on this one, but it may or may not be insightful to hear the perspective of someone from the outside describing what they believe a BA is. I am happy to have my view corrected though.

A Subject Matter Expert (SME) while often employed under the guise of a BA title, in my mind is not one. The software developer who has grown tired of the never ending chasing of the technological tail and has "retired" to the BA role, is also not necessarily one.

The two main attributes required of a BA are:

1. A facilitator; they act as a communications bridge between management and operations in the business, as well as between the business and technology. Sometimes even as representative of their company, in the communications with external parties. For this they require a number of skills and tools such as being able to:
  • manage meetings with people from a range of disciplines
  • identify appropriate stakeholders
  • networking across disciplines and business units
  • communicate to and alleviate concerns of the various stakeholders with tailored messages to each group
  • manage stakeholder expectations
  • create presentations, and present to various stakeholder groups, of varying size audiences
  • convey concepts, ideas, details
  • generate enthusiasm, sell a vision, keep the dream alive
This requires some knowledge of various disciplines, from the business domain through to the technical domain, as well capability in the tools of the trade.

2. An Analyst; with an understanding of the business domain, the ability to analyse inputs, outputs and stakeholders, map processes, identify deficiencies, envisage and communicate potential solutions, perform cost analysis and projections, understand and represent The Business in its needs, being able to identify and articulate the detail that they cannot, and helping to ensure that the target vision is being met with any deliverable.

But most importantly, a BA is not an island of knowledge. A BA is a member of a multi-disciplined intelligent team, where ego is often a major contributor to internal friction, but where it has no place. They need to avoid being proscriptive in their proposed solutions, and for the best chance of success within a project environment, they need to take a collaborative approach.

Both The Business and the IT team have a dependency on the BA's, but when the BA acts alone and arbitrarily as with any other member of this team, it is to the detriment of the deliverable and all who are involved.

The Business needs to be involved for the whole project life to validate what is being developed and potentially identify new needs in light of what they have seen.

The IT team need easy and ready access to The Business. For many things, the BA acts as a representative of The Business, but for the IT team members, it is often extremely beneficial to also be able to directly interact with the target audience. Ideally (though in practice it seldom if ever happens), all team members would have some exposure, if not hands on experience, within the target environment so that they can have some appreciation of the potential impact of their decisions.

It is also important for the IT team to be reviewing requirements, even if in draft form and contributing to estimates and decisions from the inception of the project. Often the IT team are brought in only after the requirements have been "finalised".

Which neatly segues into the next section.

What is the role of a BA in an Agile project?
There are a growing plethora of urban myths around what an Agile project is and what it can achieve, and this posting cannot do any justice in addressing them, so I will not attempt to. There are also quite a number of criticism's emerging around Agile, some of which are in my opinion quite valid. Again, I am not going to attempt to address them in this post. The following will likely make me sound like a strong advocate of Agile processes. In truth, while I see much benefit from the process approach, I am also somewhat critical of it. But that can be left for another day.

To understand a BA's role in an agile project, it is important to understand what an Agile project is.

I guess the best place to start is the Agile manifesto. There are a number of Agile methodologies, but the two most commonly encountered are probably eXtreme Programming (XP) and Scrum. There are a number of methodologies jumping on the bandwagon of Agile, that are mostly Agile in name only. While it seems to be growing in popularity in the business domain, Six Sigma in my mind is one such example that is not an Agile methodology, despite its coupling of late with Lean, out of which the principles of Agile have their origins.

Essentially, the main focus of an agile project is to reduce the feed back loop from the time something is requested, to the time it is validated. At the micro level, this involves practices such as continuous build environments, Test Driven Development, daily stand up meetings, and Pair Programming up to the macro level where iterations are kept to short durations and feedback elicited from the target user as often as possible.

There is also greater emphasis on interdisciplinary cooperation within an Agile project. The traditional process is horizontally layered, where each layer is the responsibility of a dedicated team of specialists, and they have little interaction with team members of other layers. Typically it would be layered something similar to the following:

The Business (receipt of project)

Production Support and Migration Teams

Testing Team

Software Development Team/Infrastructure Team

Business Analysts (requirements gathering)

The Business (request for project)

In an Agile process, it is more vertical, with the above structure turned 90 degrees. Ideally, you would have a representative from each layer in a collaborative co-located team, and the team as a unit is responsible for seeing one "story" proceed from inception through to completion. In a full XP model, these team members would be swapped between teams by up to twice a day so that everyone has an understanding of all aspects of the project and the key man risk is mitigated.

This does not mean that requirements gathering, or documentation is no longer needed. However, the process of capturing them and the format they are captured in will not be likely to be as per a traditional process. Decisions still need to be made, recorded and prioritised, rules still need to be captured and referenced, processes still need to be mapped, communications still need to be compiled and disseminated.

These are the skills that BA's are meant to be competent in, if not their speciality, and cannot be replaced simply by the developers and testers having direct access to, and talking directly with The Business to validate things for themselves. Those communications will still require facilitation. In a pure XP implementation, there would be no BA, only The Business involved in requirements elicitation and functional and user acceptance testing. However, in reality, even SME's from The Business often lack the skills to adequately do this task, and this is where the role of the BA can help fill this space.

An Agile project is fast paced, consisting of consecutive short sharp development cycles for the members of these sub teams. One of the biggest challenges for a BA is to be able to capture the requirements to a sufficient level of detail for the developer and tester within the current iteration, inside of the required time available, without leaving the developers waiting, while still being available to field any questions with minimal response time from both developers and testers.

If anything it arguably requires a BA to be even more capable and disciplined on an Agile project than with any other methodology.

Additionally, not all solutions involve IT. It is my opinion, that IT solutions should only be seen as a last resort, not because of the human impact factor, but because of the high risk associated with IT project deliverables, not just in cost and schedule but also acceptance and fit for purpose, when often there is likely to be a cheaper, lower risk alternative in business process change.

Unfortunately, we seldom model the risk aspect into our valuations of alternatives. But even with a purely business orientated process change, there is no reason why such an initiative could not also be done using Agile principles.

I should point out though, that I am painting the picture of a BA's role in a large corporate environment. For small web development outfits, who usually do not employ BA's anyway, going Agile for them will not change their perceived lack of need for a BA.

What is the future of Agile?
It is always dangerous to Crystal Ball gaze, but here goes for the next few years.

Many large corporations have commenced using some form of Agile in some of their development. This penetration into the corporate IT industry will continue to increase.

Many small outfits risk tarnishing Agile with cowboy behaviour masked under the aegis of "Agile", when in reality they are not following anything but a chaotic methodology.

The hype will begin to dissipate as per every previous "silver bullet" to hit the industry over the last 50 years, and the Agile zealots will be marginalised and voices increasingly ignored as Agile is absorbed and morphed into something else that deals with distributed development teams of varying mediocrity, and silo corporate entities across which even the smallest of corporate projects find the need to navigate.

The focus of project management will begin to change to be more inclusive of all stakeholders, which can only be a good thing, and there will be an increasing expectation from customers for earlier deliverables of incremental releases, which will change how system testers need to approach regression testing, and production access is modified to allow more frequent migrations. Project managers will have a wider range of tools and strategies from which to choose to apply to a project, and the increasing support of the corporation in using them.

There will be increasing tension between the likes of CMMI/SPICE/V-Model processes and Agile based methodologies, including with the likes of government contractors, as Agile projects struggle for official endorsement and recognition as valid methodologies.

But at the end of the day, there will still be a need in the corporate space for a BA, regardless of the process used on the project.


27 February 2008

Time Tracking Series: Table of Contents

Time Tracking Series Table of Contents

Janet Rolsma, a member of the newly formed “Better Projects team” has produced an excellent series on the benefits, mechanics and techniques of time tracking for projects. A vast improvement to my initial comments on the topic back in 2005.

Here are the articles in order;

How to make the data meaningful

To continue the discussion from here and here:

Once you convince people to do time tracking, you need to remember that there are different goals to be addressed. If you are a consultant, you need to track time for billing purposes. If you are a project manager, you need to track time for measurement purposes (Are we on track? How's our Earned Value Management (EVM)?). If you are a department manager, you need to track time for reporting purposes. The problem is that each of those goals requires a different type of time tracking.

A common argument with my systems architect friends is over whether you should track time spent on a task or elapsed time for a task. When planning a project, you need to know what the elapsed time is for a given task. For example, if you are working with large dataset calculations the job may run for a significant amount of time but it may only take a few minutes for someone to submit the job to run. Do you track the running time or the person hours?

Somehow I can't convince them that I need to know both. One is for billing purposes, the other for project management purposes, and both for reporting purposes. You don't want to double bill your customer for time, so you don't bill the run time, just the submit time. However, you don't want to miss out on a task that could be part of your critical path if the job that needs to run takes more than a day. In addition, management has to report to executive management on staffing, project delivery dates, future staff planning, etc.

It turns out that this conflict is easier to manage than it sounds. Simply use two separate tasks - one that is a work resource for the submit task and one that is a material resource for the actual run time. This will get you all the data you need. You can track the actual time spent by your people for all the billing and staffing reports you need and you will have the calendar time for the project delivery dates you need.

Does anyone have any other (or better) ideas on how to manage this sort of thing? Has anyone worked with a tool that supported this easily?



Some thoughts on ethics for project managers


25 February 2008

What type of Analyst are you?

Click on the image for a larger version.


The role of the business analyst is a diverse one. What you do and how you do it depends on many things, such as the industry you work in and the size of the organisation you work for.

It seems to me though that there are a couple of key dimensions that delineate types of analysts.

These dimensions are;
  • Are you working in IT or in the business side of the organisation
  • Are you working on keeping today's operations running smoothly or are you working on the future of the business?
  • And if you are working on the future, is it next year's future or further ahead?

How is this useful?

It gives you some idea of the breadth and complexity of the role itself. It also highlights career choices you can make as ou develop professionally. And thirdly it shows where your skills are clusterred and where (or who) you can go to enhance or complement them.

22 February 2008

The mechanics of time tracking

It isn't easy to manage the problem of getting people to do their time tracking. No matter how many good reasons there are to do time tracking, people still don't see the value until after you show them instances of one of the examples from yesterday’s post.

The fact is that time tracking does add overhead to your day. However, if you plan it correctly, it shouldn’t add more than a few minutes a day and the advantages far outweigh the time spent.

One recommended practice to limit the overhead of reporting is to have your team do self reporting of time spent. This is beneficial in terms of accuracy and it limits the overhead to a few minutes per person rather than a huge chunk of time for a single project manager.

In order to minimize the overhead, your time tracking system should be simple, easy to use, and easy to data mine. I have found that even the simplest of methods can be effective. A simple list of projects with a subcategory of milestones or even project phases will work. In fact, if you get into too much detail, the overhead of tracking quickly gets out of hand.

The tool isn’t important unless it is too difficult to use. I have used open source systems, Excel spreadsheets, a simple mod_perl script run in a web page, a Sharepoint task list, and an off the shelf product. The hardest to use was the Excel spreadsheet and that was because I had to combine data from 12 different people into one report.

It doesn’t have to be fancy; it merely needs to be meaningful.

Tomorrow: how to make the data meaningful.

21 February 2008

Good reasons to do time tracking

In all the years I've worked in IT, I have never found anyone who didn't have strong feelings about time tracking.

Most people I know hate doing it and they all have the same reasons. "It's too much overhead." "I feel like a lawyer." "I don't know what I did today." The only people I've met who like time tracking are the ones responsible for measurement and analysis of project performance.

The one person I've met who loved time tracking came from a Six Sigma background.

There are many reasons that time tracking is important. In order to make strategic decisions, you need data. The only place to get data that can be aggregated is to have the detail that rolls up. The types of decisions that have been made based on the time tracking data I've collected over the years include:
  • Staffing - Several people avoided layoffs because I could show exactly what they were working on and how long they spent doing it. We also could show that we needed more people in order to do additional projects in the time frame management required it.
  • Project delivery dates - Because we had good historical data on actual times vs. estimates, our estimates were given more credibility by management. Instead of management insisting on an unreasonable delivery date, they accepted ours.
  • Planning when new projects could be started - When management saw that staff was fully loaded for the next few months, they reprioritized their projects to fit the staffing schedule.
True story: Once upon a time, my boss was asked for a report showing on which projects the department was spending their time. After several days and much heartache and grief, he received numbers from all of his people and created a report for management. Management not only disregarded his numbers, they made some staffing decisions based on what they believed rather than the report he had given them.

About a year and a half later, and six months after a time tracking system had been implemented, management asked the same question. After about 2 hours of wrestling Excel into a meaningful graph, the report was delivered to management. Staffing decisions from far up the food chain were adjusted based on the actual numbers he sent.

I know what you're all wondering. The answer is, the actual numbers were well within a reasonable range of the original estimates.

The moral of the story is whether you know what your people do or not, it always makes a bigger impact on management to be able to show actual data proving your point.

Tomorrow: the mechanics of time tracking.


Photo by Padawanchina
and originally posted here

18 February 2008

Rapid Application Development

I like this diagram because it has blinking lights.

Rapid Application Development is no mystery. For many years now people have known the best way to get requirements verified and validated is to build a prototype.

If you can get a working model in fron of people you can get really good discussions going about what features are most important and why. You can also use the prototype to manage people's expectations about what isn't going in to the end product.

Even if you don't have the resources of a developer to put together a prototype you can still model a system using powerpoint, or even white boards. (This is probably where use cases originated.)

RAD is prototyping as a project management methodology, but prototyping belongs in any type of softare development project.

The picture came from http://www.21stsoft.com/ and there is an article xplaining it here.

17 February 2008

Going out of your way



"To form an effective relationship, a relationship of genuine service, the client needs to see that you are going out of your way."





Cope, B & Kalantzis M (1997) ‘Management Lessons from Australian Companies’. Presented jointly by Dr Bill Cope & Professor Mary Kalantzis 24/10/1997.



Photo sourced from

10 Tips for finding hidden requirements

Catalyze Webcast - Finding Requirements - 092007

As part of the Catalyze webcast series, Carol Miller will show us that there's more than one way to find a requirement in our second Catalyze webcast originally broadcast on September 20, 2007.

Carol is the VP of Professional Development for Advanced Concepts Center (ACC) and is also the VP of Professional Development for the Philadelphia chapter of the IIBA.

SlideShare Link


Business Case-Studies, Models and Design Principles

This talk addresses three major challenges of value network-driven enterprise analysis:

(1) unifying the business knowledge of multiple enterprises and their diverse and conflicting objectives in the value network,

(2) sensing the value network and processes through systems design, and

3) analyzing the value offered by multiple service entities in the network based on common goals and metrics.

14 February 2008

A beginners guide to Enterprise Architecture

Here are some Enterprise Archiecture resources that may assist in your research on the topic. They are presented as a starting point for research into the role and the issues that the profession faces today.

Your comments about the contents are encouraged as I am fairly new to the topic. Any other suggestions for inclusion on this list are very welcome.

12 February 2008

NICE Requirements

If you are involved in defining and managing software requirements you really should be reading Scott Sehlhorst's Tyner Blain blog.

If you are reading it then you already know about his neat addition to the world's myriad of acronyms with NICE requirements.

NICE? Naive, Incomprehensible, Complex and Elegant (like the model.)

Click through and read the whole post.


Heuristics

A reader recently wrote and asked how to approach a first client meeting regarding a Business Intelligence project.

(I referred him to the Modern Analyst forums where you can get great answers to questions like this.)

It did get me thinking about how you walk into that sort of meeting, cold, no chance to prepare and come out with some useful information (and looking professional and in control.)

There are a heap of techniques available for this sort of meeting. Myself – I find it best to start with a high level view; what are the project objectives and how will they benefit the client? What constraints exist for the project? What opportunities are there?

If you want to drill further into the detail, or if you want some structure to help you through the meeting, you can use the magic questions: Who, What, Why, When, Where and How?

Write these words down and check them off as you ask a question that begins with each word. By the end you should have a solid amount of information that will set up your next phase of investigative work.

Wrap the meeting up by checking whether there are other people you should be speaking with and get their contact details. Always, always, make sure you have identified all the stakeholders.


Photo originally by Tim O'Brien
sourced from Flickr here

11 February 2008

Alltop.com

Not strictly on-topic, but we found a link.

Alltop is an example of an Agile approach to product development by Guy Kawasaki.

Probably not the most technical whizz bangery ever thought up, but a neat site nonetheless.

Visit Alltop and enjoy.


Photo originally by vattenpuss
and lifted from here

lean thinking and lean doing

Lean thinking is a way of looking at how your work is done and striving to be constantly more efficient.

A part of the framework is decentralising control of the work; the people who are doing the work activities are the best informed about how they can be improved.

Of course Lean comes from a manufacturing environment, but service organisations are also looking to implement lean thinking into their business practices.

It raises some interesting challenges. For example, often service industries operate in highly regulated environments. How do you decentralise decision making and at the same time manage to ensure regulations and legal requirements are all maintained?

One reasonably effective method I am familiar with is allowing frontline troops to manage how their work is done, but control it via a central “business Process” repository, kind of like a configuration management database (CMDB for the acronym heads.)

To do this you have to invest in a few things; an up front documentation of existing processes, hiring people to manage the processes change control, a tool to store your newfound ‘controlled knowledge’, and last but not least a change management programme that helps your frontline people work with the process controllers.

I have also seen processes management effectively using a TQM approach where the process improvers are removed from frontline teams and put to work improving efficiency.

It can work, but there needs to be an excellent interface between the frontline business units and the process analysis team.

Without a highly client centric approach from your process improvement team, this mode becomes a bureaucracy that is likely to slow down your organisations ability to change, and increase the cost of doing business. All the while increasing the frustration levels of your customers.

Any other stories out there about how to manage frontline process improvements?
Photo from the Library of Congress
and sourced from here

10 February 2008

International Community for Project Managers

From the Youtube blurb; "Visit www.projectmanagementlearningcenter.com Network yourself, build a profile and make connections with your peers in the Project Management Industry! This collaborative PM community promotes the creation, development, integration, sharing, and application of Project Management knowledge for the benefit of humanity and the profession."

7 February 2008

Whole Team Collaboration

Josh Graham at Virtual Surreality has a blog on Software development. One of his recent posts caught my eye.

His post on Whole Team Collaboration appears to be a diagram that shows the boundary spanning areas of project teams. Its a way of looking at how business interacts and reminds me of a post I wrote on business analyst knowledge domains.

Click the image for a larger view.




Cinda Voegtli: Executive Views on PMs

Cinda, founder of the Project Connextions website has wriiten an article on the perspectives of executive 'customers' of prject managers.

The leader for the article;

"You know how to do status reports. You're confident about your scheduling and work breakdown skills. You have the methodology binder memorized. You know what you're doing, and you're pretty good at doing it. Would it surprise you if your executive "customers" aren't really all that concerned about it?"

I enjoyed the article because it mirrored my view on how project should be run.

That is; you have a business client/customer and you are there to service their need. Technology solutions that do more or less than that are not the nest solution.

The best way to make sure you are aligned with their need and expectations is to talk with them. And as you run your project, keep talking to them to make sure you are on track.

It sounds simple to say it, doesn't it?

Read her article here.

6 February 2008

Rights

You can draw useful lessons from a variety of places. Back when I was an undergraduate student, amongst other things, I studied politics. One of the discussions we had was whether Australia should adopt a bill of rights.

Many readers will instantly jump to the conclusion that of course a bill of rights is an excellent thing, as it protects the rights of the citizens, and especially those from minority and disenfranchised groups.

Well, there are arguments both for and against a bill of rights. A summary of some of the arguments can be read here.

How does this relate to requirements management?
For a start, it's a warning to think through your assumptions, but that is pretty obvious and you don't need to be reminded of that (today).

The point I wanted to suggest is more specific; when defining requirements and designing solutions, be aware that if you entrench certain rights for users - in either systems or processes - you may be forcing them into a mode of operation that someday in the future will fail the business and the customers.






The photo is care of El Fotopakismo at Flickr.
You can see he original here.

Help Wanted

You don't have to be an expert but you do need to be enthusiastic.

Hi readers,

I have a number of topics and ideas I want to explore but find it hard to fit it all in to my week.

So, I am looking for someone to help me put this blog together.

What I am looking for is someone who isn't shy about putting your ideas out in public.

Of course, you should also be interested in the effective management of projects.

But you don’t have to be an expert. You just have to be enthusiastic enough to put a post together at least once per week.

If you don’t know where you would start writing, I’ll be able to work with you on shaping up topics.

I also expect we will write several articles together. And not everything will be published here. Sometimes we’ll send an article off to other sites.

Anyone out there want to take the plunge?

Email me to talk about it further!





5 February 2008

Enterprise Architecture and Business Analysis

There is a community of Enterprise Architects out there with a handful of activie bloggers. (You may have read my post a few days ago from Nick Malik for example.)

When you look at the role of the EA you see it's about planning and macro level design of the technology environment of an organisation. It addreses the need to balance the short term needs to get things done with the need for a scalable an uncertain future.

The Enterpise Architects I have met came to the role from business analysis, so it's not surprising that the BABOK (v1.6) identifies Enterprise Analysis as one of the key knowledge areas for Business Analysts. (Solution architects I know tend to have been developers.)

"Enterprise Analysis is the Knowledge Area of the Business Analysis Body of Knowledge (BA BoK) that describes the Business Analysis activities that take place for organizations to

  1. identify business opportunities,
  2. Build their Business Architecture framework, and
  3. determine the optimum project investment path for the enterprise, including implementation of new business and technical system solutions."

The BABOK goes on to characterise Enterprise Analysis as mainly pre-project work that is involved in project portfolio planning, feasibility studies, strategic planning and busienss architecture.

It's focus is on the business side of the business/technology divide, but as a consequence of that macro level view technology infrastructure is included in it's application.

The Business Architecture describes the businesses strategy, its long term goals and objectives, the high level business environment through a process or functional view, the technological environment, and the external environment. It also defines the relevant stakeholders, such as the government, regulatory agencies, customers, employees, etc.

According to the BABOK, business architecure is one of five dimensions of Enterprise Architecture;

    1. Business Architecture
    2. Information Architecture
    3. Application Architecture
    4. Technology Architecture
    5. Security Architecture

This context is interesting and is part of a wider conversation about the degree to which IT drives business decisions and how appropriate that is.

I am sure it is one our Enterprise Architect friends have views on.




Enterprise Architect

4 February 2008

Difficult customers

Sometimes you just want to honestly say what you think about the situation.

Best Practice and ITIL

Now that I have discoverred the IT Sceptic I am enjoying it quite a bit. For example, he challenges the concept of 'Best Practice' in a dynamic and diverse industry like IT. It is asking for trouble.

"Once again, it is not ITIL itself that I (or the author) am taking a tilt at. This time it is that concept of Best Practice. I much prefer the term Generally Accepted Practice... You just inflate expectations and attach a note to your backside saying 'kick me'."

We all get sceptical of things that are said and done around the corporate office. Often it is rooted in people's practice of jumping onto the next big idea without taking the time to undertand it properly.

When adopting new ideas, take the time to understand them first, and then adopt them to your context second.




ITIL is cool and refreshing

In case you are not familiar with ITIL here are some resources for you to go do your own research.

(I got this picture from a post about ITIL for small-medium businesses called ITIL is Essential.)

Project Management and ITIL Release Management

PM Hut has an article on the difference between project management and ITIL release management.

The key difference seems to be that projects are finite and releases go on forever. Apart from that good system management shares a lot with project management.

Early this decade I spent some time as a systems analyst. The team I was in managed escalated service issues, releases and administration processes such as the budget and user access.

It was an interesting and high performing team and I learned quite a bit about good system management processes from them. The team approached the management of ther systems in a very planned and structured way that left space to deal with crises when they came up.

Principles from project management were applied to everything they did. Let me run through a few examples;

  • Releases were planned many months in advance, withy resources and funds allocated and work prioritised.
  • Stakeholders were engaged and planned changes were communicated broadly. The communicatons were planned and monitorred.
  • Risks and issues were actively managed.
  • The potential benefits were carefully assessed before budgets were allocated.
  • Changes to business requirements (ie enhancements) were managed in a controlled fashion.

Additionally, individual releases can be 'project managed' even to the stage of benefits realisation. The two frameworks go together well.

Do any ITIL practitioners have a view on this?

  • 3 February 2008

    Accelerating Innovation: People, Processes, & Technology

    On March 14, 2006, Jack Shaw, President of Intelligent Healthcare Technologies, gave the Keynote Speech to over 2000 executives attending SAP Brazil's 2006 User Forum in Sao Paulo -- the largest annual IT conference in South America. In this hour-long presentation, Jack discusses topics ranging from Innovation to Dynamic Business Process Management to Cognitive Systems.

    Jack talks about innovative approaches to business. His vision is of a smarter industry; automation, self managing systems and so on. Watch this before you next scope a project or specify business requirements.

    2 February 2008

    Carnival of Business Analysts #6: Requirements Communication




    Welcome to another edition of the Carnival of Business Analysts. Regular readers know we are tracking through the knowledge areas of the BA BOK (version 1.6.) The Carnival of Business Analysts seeks out blog posts on the topic of business analysis.

    Each month I have nominated a theme and then hunted down posts related to that theme. I am assisted by a handful of bloggers who nominate posts they have written or read, and together we construct this digest of thinking on the edition's monthly theme.

    In the first 5 editions we have covered Requirements Planning, Requirements Elicitation, Requirements Analysis, The BA and Quality and the nature of the Business Analyst Role. (You can see the whole list here.)

    This is edition #6 and it focuses on Requirements Communication.

    To start with, read a quick definition or Requirements Communications from the BA Handbook on the knowledge area.

    Then, to reinforce that communications is an important and troubled part of requirements management read what Mike has to say about communication at Leading Answers in “We Don’t Want User Input” Angie at B2T also asks When you communicate is anyone listening? And following on from this there is a post at Seilevel titled “I’m not going to read your requirements.

    So you can see there is a challenge in managing people’s communications bandwidth.

    Looking more broadly, are there lessons we can learn from other industries? Nada Serajnik has written a post called Can We Learn From A Public Communication Campaign? And Cinda Voegtli tells us What the Girl Scouts Could Teach Us About Project Communication.

    Dave Bouman sums it up with the though that regardless of how you manage your software development, at the end of the day “It's all about Communication...

    So how do we manage requirements communication? James Brausch has put forward a model that may be useful in Four Types Of Systems

    Lastly Fred W Black reminds us that “Honesty” is a fundamental to good communication.

    This edtion is a bit shorter than usual. I have been busy and so haven’t had the time to search as deeply as usual for content. If anyone has something they’d like to add, please do so in the comments.

    That concludes this edition. Submit your blog article to the next edition of the Carnival of business analysts using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

    Next edition will be published 10th March and will be themed on Solution Assessment and Validation.