31 August 2007

Reminder: Carnival of Business Analysts #2

Hi readers,

A reminder to submit your articles and blog posts on Business Analysts and Quality. I'll publish the next edition of the Carnival of Business Analysts on Monday

A reminder of posting guidelines;
  • Be relevant to the topic of business analysis; the focus is on the type of business anlaysis associated with projects and change management, not so much on pure financial analysis
  • One post per author per edition; If you have lots of good posts you can spread them over multiple editions.
  • Add a short introduction to your article when submitting; This will appear on the carnival as the intro to your article.
Thanks for helping out.

27 August 2007

A critique of Agile as the new way

The Agile Method and Other Fairly Tales, by David Longstreet is quite a strong argument for why you are unlikely to get results from switching to an agile development methodology.

When you read the article you find the argument compelling.

If you are considering the methodology, or if you are a die hard fan this is probably an important article to read.

David is an IT professional, but is also a statistician and financial analyst. His broad industry observations are that agile isn't delivering results and that the real place to focus attention is on a quality approach to requirements management.

Read the article here.

No doubt the title should be The Agile Method and Other Fairy Tales. I also hear that Longstret is doing a talk on this topic for Atlanta SPIN soon.

==added 10th Sept==

David's offers his background in more detail;

I started this software journey as a programmer. My first software language was machine instructional cross assembler. It was basically hexadecimal machine language. I could really pump that stuff out. Early in my career I wrote Fortran code for theoretical physicists solving complex mathematical equations. Over my career I programmed in COBOL, C, C++, and Java. I actually co-authored a DOS 5.0 book that is obsolete now. Prior to becoming a consultant, I managed software developers, testers and production support teams. I have managed both technical staff and functional groups. I started out with punch cards and now I use a Mac.

For over two decades of my life I have been dedicated to the idea of improving software productivity and quality. I have traveled the globe consulting and studying software organizations that support just about every industry including banking, aerospace, retailers, animal food, telephone, consulting companies, healthcare, defense contractors, package delivery, automotive, travel, government agencies, and insurance. I have worked for organizations with only a few employees and others with billion dollar budgets.


26 August 2007

The 5 Minds of a Project Manager

In 2003 Henry Mintzberg and Jonathan Gosling published The Five Minds of a Manager in HBR.

If you know Mintzberg’s recent work you know the gist of the article already; management education is generally flawed in it’s approach to building up functional competencies without the context of the need to integrate work. The article’s abstract sums up the challenge concisely;

“Managers are told: Be global and be local. Collaborate and compete. Change perpetually, and maintain order. Make the numbers while nurturing your people.

To be effective, managers need to consider the juxtapositions in order to arrive at a deep integration of these seemingly contradictory concerns. That means they must focus not only on what they have to accomplish but also on how they have to think.”

The article highlights five key asks managers need to be good at managing.

  • The self (the reflective mind-set)
  • Organizations (the analytic mind-set)
  • Context (the worldly mind-set)
  • Relationships (the collaborative mind-set), and
  • Change (the action mind-set).

The PMBOK already discusses the knowledge area of integration. Integration in the PMBOK takes a typically functional approach. It is about ensuring your project plan is an integrated and coordinated document, that your execution of the plan is integrated (ie makes sense in the way it’s done) and in managing change into the process effectively.

Integration is more than integrating documents to work actions though. It incorporates the management ideas of Gosling and Mintzberg. The document and task integration are servants to these higher level integration activities. Projects are managed and executed by people, and those people come together and form an organisation; the project team.

You can buy the article here: The Five Minds of a Manager. Also, a blogger called Sambit has reviewed the article from a general management perspective.



photo care of flickr

25 August 2007

Religious wars

Eric thinks it's a red herring and methodology is not the issue. It's people.

Agile or waterfall can work, he says, if you have a good team. People trump process as Scott Sehlhorst often says. That means good people can work with a bad process right? It still doesn't answer the question of which model is better.

Maybe you just run with no formal process and work it out as you go. Oh yeah - that's agile.

But of course you don't always get the best people. What do you do then? Run them through a hard to manage and heavily bureaucratic process that even masters have trouble with?

The answer has to be the middle ground. Why aren't people talking about it? Or if they are - where are they?


The problem with Six Sigma projects

Has anybody noticed that six sigma doesn't have a change control process attached to it?

Are there a million six sigma practitioners out there who can't manage their scope properly? Do your sponsors keep adding one more thing? Are you still trying to close off last year's projects?

If you are stuck in this groove and want to change the tune consider adding in the PMBOK change control process to your framework.

I promise you that work gets easier when you manage your scope tightly.

22 August 2007

What is a Systems Analyst?



Balanced Scorecard for Project Success

The Balanced Scorecard is a management concept that says there is/should be more that one imperative for success. At high level it considers success, or effectiveness, to be a balance across financial, strategic, customer and internal process compliance.

Operations management have been using this framework for a few years now. Projects can learn from it.

Projects, especially software projects, have a hard time satisfying clients and here is a way of getting client satisfaction onto the agenda alongside time, cost and quality (scope delivery.) It also puts quality management up there on the list of key success factors.

Your balanced scorecard doesn't have to be the usual financial, process, strategy and customer effectiveness measures. You can mix and match your own set of agendas that need balancing. You can weight them as you think appropriate. Or you can take on the vanilla model.

Either way it's a fresh way for project managers to approach the definition of success. Do you think you could pull it off on your current or next project?

Post inspired by this presentation from "Strategy, Change and Project Management"


What is a Business Analyst (again)

You will have to log on to view it, but the Requirements Networking Group has posted an article on the role of a business analyst from a recuiter's point of view (thanks Scott.)

I've added a link to this article from the Carnival of Busniess Analysts #1 (where the theme was defining the role.)

Particularly useful for those of you thinking about applying for a job as a BA in the industry. The article also has a discussion thread that is worth a look.

You can link to the article from here.

20 August 2007

Project Management and Project Leadership

Project management is typically not an activity carried out at the strategic apex of an organisation. More commonly it’s an activity that happens in middle to lower management, and it’s usually tactical, even though strategic management skills are often needed.

Project management is about the development and execution of a plan, and that plan is in response to a business problem or opportunity that an executive sponsor or other manager has prioritised to the top of the queue.

Project managers and project team members are experts in execution and these days it’s a very important skill.

There is a lot of focus in the PM press at the moment on the importance of soft skills; managing teams, stakeholders, suppliers and sponsors. And a common discussion in management classes – both for project managers and for MBAs is a discussion about the difference between management and leadership. The tendency is for people to think leadership is more important than management, but that’s not true. The real answer is that it depends on the context and environment.

And for the project environment where there are a number of specialists coming together to collaborate as a team there’s even less need to put one person forward as a leader. Everyone should take their turn at leadership, when their skills are called upon, and where they see a gap in the team’s performance as a group. And everyone in the team should step out of the way when someone else has the ball, and let them work to their best within their area of expertise.

What does this mean for project managers? It means that project managers should manage first and lead only when it’s their turn. Let the team members take leadership roles when it’s their time. Project managers should be experts in leading from the rear.

Henry Mintzberg, management guru agrees:

“Isn’t it time to think of our organizations as communities of cooperation, and in so doing put leadership in its place: not gone, but alongside other important social processes.”
And -

“...to recognize that the very use of the word leadership tilts thinking toward the individual and away from the community.”
You can read his article to learn more on his views on leadership here:





18 August 2007

14 Key Management Skills

The PMBOK mainly talks about the technical aspects to planning an doing work on projects. It identifies that general management skills are a key part of the puzzle, but then refers you to the management literature and you are expected to go off and read, study and assimilate that info. In that vein I provide some information on management theory for you.

I have been reading a fascinating book by Cameron and Quinn called Diagnosing and Changing Organisational Culture. If you are a manager of people (and what project manager isn't) or if you are working as a change agent this book is full of useful ideas.

The first that I learned from this book is the competing values framework, which essentially divides organisational culture into four quadrants, based upon two dimensions; internal versus external focus, and degree of control versus flexibility. I'll post more on competing values again.

The book then plots a framework out for identifying what areas need to change and some ideas on how that change should be managed. One of the steps in managing change, for example, is ensuring your middle managers are capable of the changes required and tht they have the management competencies you want in your future business model.

Supporting this idea the authors present a list of 14 management skills the authors consider to be baseline management competencies you need to be successful. The degree to which these skills depends on the needs of the organisation at any time. Here's a list, mapped onto their Competing Values quadrants. It's presented as a teaser of what's in the book.


I am particularly interested in the people side of project management - both on the projct teams and the people who's job you are affecting. There are plenty of new ideas in this book worth learning about. I highly recommend reading it.

Get it here; Diagnosing and Changing Organisational Culture Based on the Competing Values Framework.

A Carnival of Business Analysts #2

It’s time to remind you about the Carnival of Business Analysts #2

This month the theme will be: The Business Analyst and Quality.

So bloggers and readers (you can nominate someone else’s post) head over to the submission form and lodge an article before the last weekend of the month.



17 August 2007

Process Analysis 101 - Part 4; Constraints & Data

This is the fourth post about some techniques you can use to ensure you do good quality work when eliciting, documenting and analysing business processes.

You've already considered the scope of the process step you are looking at via it's verb/noun name, and at the inputs and outputs of the process step.

You now want to consider the data and constraints that affect or are required for this process step to operate properly.

For example, if the process step is to capture a customers user-name and password you need to identify that the data elements include both the customers' username and password. Furthermore there may be constraints; the username and password may have to comply with a security policy that requires both alpha and numeric characters in the password.

Data and constraints apply both to automated and manual processes.

Neither data nor constraints are actually part of the process and so typically would not be included in a process diagram, but they are relevant and useful and as such as useful to capture. Grabbing them while in a workshop with the experts saves time and revisiting them later.

Constraints
Constraints are often driven by external stakeholders to the project or product team, and it's important to know who they are early and what these constraints may be. Common examples I have dealt with include ones internal to the organisation such as corporate security policies and banding, and external constraints include things such as government regulation and legislation around privacy and opt-in/out direct marketing laws. Naturally there are plenty of others.

Data
Data can include specific artefacts such as the name and password examples above, but can also include complex and sophisticated things such as business rules and policies. Most data is typically not changing during the transformation caused by the process.

Some data does change, and if something is changing it would be the noun subject of the process step. So if you are changing a password the process step may read "Change password" and naturally the active password will change. Data that should still be captured includes the old password, the time of the change and the new password, not to mention the business rules around password maintenance.




16 August 2007

Process Analysis 101 - Part 3; Inputs and Outputs

This is the third post about some techniques you can use to ensure you do good quality work when eliciting, documenting and analysing business processes.

When documenting business processes in workshops, interviews and other forums there are a number of useful techniques you can apply that will ensure your elicitation of data and analysis are of a high quality.

When analysing processes you are identifying the sequential steps of value adding and transformational activities that (typically) help fulfil customer needs. Each step should be linked to the ones before and after it by their entry and exit criteria, or by their inputs and outputs.

Extending my previous example; the inputs and outputs around scheduling a technician visit may be a customer calling and asking for a service activation and the confirmation of the order on the technician’s daily job list.

There are all sorts of inputs and outputs, but what you should do when capturing process steps is listen to ensure that you are clear about each input and output and that there is a logical and sequential ink between the steps.

If you come across gaps as you go through your elicitation process you need to back up and question the subject matter expert about what’s going on. Have they skipped a step in their description? Have they described activities out of sequence? Or is there a flaw in the business process.

If it’s one of the former you can sort the problem out by more careful questioning and investigation. If it’s a case of the latter then this is your opportunity to improve the process, or avoid migrating the problem forward into the new post project state.

15 August 2007

Process Analysis 101 - Part 2; Labelling Process Steps

This is the second is a series of posts about business process analysis. The series is focused on the basics of analysing steps in processes. This post focuses on the importance of labelling the procss step.

Transformation
Remember a business process is a transformational activity and that each of the steps along the way are designed to assist in the transformation. In the phone company example from the first post the transformation was of the customer’s state from not having a phone service to having a working phone one established at their home.

Each process step along the larger business process is also transformational in nature. Or example a step may be to schedule a technician to visit the home. The transformation is of both the technician’s state and that of the customer’s work order of unscheduled to scheduled.

Using the Verb/Noun
Describing process steps as a combination of Verb and Noun helps an analyst focus on the transformational nature of processes. You are doing something (the verb) to something (the noun.) The process step in our example would be to schedule (verb) a technician (noun).

This approach to labelling also makes descriptions more concise and consistent. If you are working in a team of process analysts you are likely to find that people have different styles of writing and different styles of describing process steps. Some people fit essays into these boxes. Others drop in a series of acronyms that are unintelligible to everyone, including themselves when they look at the diagram a month later. Using the verb/noun combo keeps language simple and standardised.

Naturally in modern corporate environments it will be a rare occasion when your process box only has two words in it. For instance, when scheduling our technicians we might do so in our Technician Scheduling System (or TSS), and we schedule them by creating a Phone Installation Work Order (or PIWO.) Yes, things can get out of hand.

But by focusing on the verb noun you will have a better chance of creating a clear document that humans from both technical and business sides of the project fence can understand

13 August 2007

Process Analysis 101 - Part 1

One of the problems project teams and business stakeholders have with defining business processes for projects is that the documentation is often ambiguous, incomplete or incorrect. This is caused by a number of things including poor understanding by subject matter experts of what the business process actually is, not allowing enough time in the project's analysis phase to fully identify and document the processes, and in people with sub-standard skills being allocated to the task.

In pursuit of better business analysis for projects everywhere I present this diagram to help analysts think about improving their process mapping and design skills.





Process diagrams are more than just boxes linked by arrows and good analysts are always looking for whether process steps are adding value or are wasteful or marginal steps. Process maps show the sequence of a series of activities, where each activity is transforming something along the way to the process's targeted outcome.

For example; when a customer calls a phone company and asks for the phone service to be connected to the house the sales person will start a process and that process will be made up of multiple smaller steps. The end result should be that the customer has a phone service switched on at their house and can make phone calls.

In the diagram presented here there are a number of attributes that I have flagged. By paying attention to these attributes when working on processes you will do a better job of documenting and analysing the process, and will be better able to design quality processes for your future state.

  • Process Step Labelling
  • Inputs & Entry Criteria
  • Outputs and Exit Criteria
  • Constraints and Data

In the next few posts I’ll discuss some aspects to these attributes that will help you better elicit, document and analyse business processes.



11 August 2007

Rational Decision Making

And on the topic of justifying decisions rather than rational decision making here is a presentation that explains how pretty much anything can be made to look feasible.




9 August 2007

Plans are useless... but planning is indispensable

“I have always found that plans are useless, but planning is indispensable.” - Dwight D. Eisenhower

Studies have found that planning will reduce project budgets by an average of 20% and duration by almost 40%.

Which studies? “Perceptions of Representatives Concerning Project Success and Pre-Project Planning Effort” from 1994. That's around the time of the forst Chaos Report which hilighted the critical rates of failure and mediocrity that IT projects were achiveing.

If you are a fan of a little less planning and a lot more action you might like to take a moment to read this article. I am interested in readers comments.




8 August 2007

The Voice of the Customer is Fallible

Listen to the “voice of the customer” - a popular catch cry for six sigma aficionados. But to what degree do customers actually know about what they want?

A colleague of mine recently lamented the customers, or users, on an agile software development project. Agile usually prioritises work to customer articulated requirements priorities. The users were only focused on avoiding negatives (eg not increasing average call handling times in a call centre) and were not focusing on the positive aspects of the solution, such as an easy to navigate user interface, or the ability to manage sales simply and quickly.

If you are going to use “Voice of the customer” you should manage it through a framework that helps extract the most important. Kano’s quality framework is an established and useful one. It gets customers to rate features as mandatory, one-dimensional or delighters.

Furthermore the management, or facilitation, should be done by an expert in requirements management. A business analyst or expert user, with strategic sensibilities and commercial acumen is the minimum expertise you should call on when managing requirements.

If an Agile project sponsor wants to hand over his star operator to be your user specialist as a reward for good service, take the time to assess whether they have what it takes to manage requirements properly for the project. If they don’t, then make sure someone on the team with the right level of expertise is there to help them through the process.

Requirements are too important to be left to tourists.

7 August 2007

There is no such thing as a corporate project?

There is no such thing as a corporate project. It's alwasy programme management, and here's why:

After my conversation with my colleague on Agile Project Management ran it's course we got talking about the different aspects of projects and how, to a degree, it’s feasible to break projects into sub-projects.

The project justification and planning work such as defining the problem, defining a solution architecture, cost estimating and strategic planning become a project within itself, with a clear definable outcome; the business case, and a go/no go decision.

The next project becomes the requirements definition, solution design and build work. Another project is the validation and implementation work. And a fourth is the change management aspect where you are tooling around with business processes, user training and so on.

Basically you are breaking the project into sub-projects by typical corporate project governance phases, but not exactly. And that’s the joy. When planning projects today many people break them into each of these stages then line then up with an end-start relationship, but that makes little sense at the execution level because you have inefficient use of resources and as many “business side” project workers will attest, too little time and effort spent on the business implementation work.

If you take this programme management approach to corporate business projects will you solve a lot of the integration and scheduling headaches? Does it make more sense when pitching your plan at the sponsor and steering committee? I think it does.

If you have any ideas about this please comment here and let me know.




6 August 2007

8 (not so) Random things about me

Mike Ramm of the blog Stop and Think! tagged me with my first meme; 8 Random Facts About Me. Because it's my first...

I have to post these rules: Each player starts with 8 random facts/habits about themselves which others do not know about them. People who are tagged need to write in their own blog and post these rules. At the end of your 8 random facts post, you must select 8 more people and leave a message at their site that they have been tagged.

1.
Despite my day job, I have an ongoing relationship with the legal profession. My first job out of university (B.Bus) was as a law clerk and I began but did not complete a law degree. A few years ago I took leave from my day job for a few months and helped my mother start up a law firm. She and my brother both work there now. I am also currently writing a thesis on how project management is a useful knowledge set for lawyers managing client cases.

2.
My Myers Briggs personality type is: ENTJ. According to the website where I did the test I should be a manager in business or education. “ENTJs have a natural tendency to marshall (sic) and direct.” So I appear to be in the right business. Steve Jobs is an ENTJ. Do the test yourself and see what it says about you. Project teams are all about balancing various strengths so that the team as a whole can do more effective work that individuals. Diversity in teams is good. Of course you need an ENTJ to run things : )

3.
According to Quinn’s Competing Values theory I am a relatively balanced manager/worker, but I secretly think my self assessment is biased and I am really oriented to risk taking. I am currently working at a bank though, so I can’t be that innovative. The Competing Values theory is fascinating to me as it highlights the importance of understanding corporate culture as a key success factor in managing change. I highly recommend reading about it and I will be posting on it in the not to distant future.

4.
I am 90% of the way through the Master and Commander book series. 19th Century naval command bears almost no resemblance to modern corporate project management, but would probably be more effective. Especially with regular cannon practice and the occasional flogging.

5.
Speaking of books, years ago I was reading Dune and thought the descriptions of the mentat though process reminded me of how full my head was getting with the details of a project I was working on.

6.
I began planning and preparing for a dot.com business 12 months ago and I still have not got it up live. Over the course of the year I have outsourced the technical work, but have needed assistance in planning and pulling together suppliers. I have worked with four people, three of whom have dropped out due to other interests. While I am researching and writing these posts I am procrastinating doing work on that project.

By the way, the latest assistant on my cunning plan is Callan Robinson who has also recently opened a new business retailing art at Zimprints which is selling canvas prints by Sydney photographers. If you want to support a budding entrepreneur and a cadre of artists go to his site and buy a print or four.

7.
I find sharing knowledge and enabling people very rewarding. I find delivering clients projects a combination of challenging, frustrating and satisfying. I find corporate culture stifling. As a result I am planning a 6 month break for the corporate world after this current job ends.

8.
As you can see I am often running multiple projects on top of the day job. Sometimes too many. The biggest project I am curently working on is a new (first) baby, due next month.

So,
Memes are an interesting way of introducing your readers to new bloggers, so now I tag the following bloggers, who I admire and recommend to you. And maybe they respond with a post and forward the meme.
Maybe.

1. Fadi at PM Hut
2. Adrian at Modern Analyst
3. Scott at Tyner Blain and Nexus
4. Jonathan at Jonathan Babcock
5. Josh at The PM Student
6. Rajeev at Portrait of a Business Analyst
7. Chris at The Business Ethics Blog
8. Rowan at Fortify your Oasis


5 August 2007

Kano model and classifying requirements

If you aren’t already using it, Kano’s quality framework is a far superior model to flagging requirements into three tiers of ‘must haves,’ ‘serious wants’ and ‘nice to haves.’

After all, good Requirements Specifications only have ‘must haves’ in them, right? If a requirement doesn’t add value it should have already been dropped.

Mandatory
These requirements will cause your stakeholders to reject the solution is they aren’t addressed. These requirements will be core to achieving the business case objectives, and meeting minimum quality standards such as security and customer privacy requirements. Most non-functional specifications will be mandatory.

One dimensional
These requirements are linear in the cost/benefit trade off. For every dollar spent on one of the requirements you’ll get two back (or whatever the appropriate ROI target is.) There may be opportunity costs as well as financial costs associated with the cost benefit analysis.

These are the requirements you will partly meet, and the degree to which you meet them will be based upon resource availability an time. These requirements are potentially easier to measure and may gain more time that they should in relation to the delighters.

Delighters
Delighters are the special features that make the customer happy with the product. A classic example is good design. You can get an excellent payback from good design but it‘s sometimes hard to quantify. Depending on the market though, delighters can be the key to success.

When dealing in intangible services project teams are often at a loss to delight their customers, especially software project teams.

Many programmers and IT workers have an engineering mindset that says work to the written specification, but that won’t make you customer happy. At best it will leave them satisfied, and usually it leaves them disappointed. Project teams should always plan to deliver a handful of delightful features into their products for the sake of client satisfaction. The job isn’t done, just because the specifications have been delivered.

The best way to do this is to have your requirements manager highlight which of the requirements fall into the delighter quadrant on Kano’s model and make sure that at last some of them get delivered.

==Added 31/8/07==

Here is an online video tutorial on the Kano model for those that like an interactive education.

4 August 2007

Communication, training, success

Projects have intimate and direct relationships with user groups. Training and communication are key aspects of a successful implementation. This is not a new insight: watch the clip.


I discoverred this clip at Beyond Blinking Lights and Acronyms.

3 August 2007

Five Things You Should Know About Software Requirements

Esther Schindler writes and article for CIO magazine on the importance of good requirements management.

She highlights 5 key things CIOs should know. Project managers and other people in authority should also take note. And as the article focuses on requirements management from developers’ points of view there is plenty of advice for business analysts.

I have listed her 5 key points below with my summary of her ideas, but don’t stop here. Read her article; it’s got plenty of well written good advice.

  • The Inconvenient Checkbox: Understand the Role of Requirements - Requirements are important, naturally.
  • Don’t Throw It Over The Wall: The Right People Should Define the Requirements - Business analysts don’t just take orders. They should be adding value by prioritising, interpreting, and understanding business needs.
  • Superficially Complete: Define Requirements With "Enough" Detail - Talk to the developers about what is enough detail; you’re writing for them. And remember; you need to be able to verify and test them.
  • Working from Ignorance: Recognize that Requirements Change - You learn more about the problem at hand as you go, and naturally early decisions in requirements and design are flawed. Accommodate the flaws.
  • Carpet Yanking: Pay Attention to the People on the Front Line - You can’t manage from status reports. Get to know your staff and listen to their views.

Read Five Things IT Managers Should Know About Software Requirements.

2 August 2007

The Myth of Agile Project Management

A colleague and I were discussing agile project management yesterday.

He had spent a few hours coaching a software development project team on some general project management principles; communications, stakeholder management, managing requirements, and was answering questions about how in you can manage an Agile project in a complex organisation.

Our conversation turned to whether there was such a thing as Agile Project Management. Sure there is agile software development, but I was of the opinion that it’s not the same thing.

The agile software development method is defined (in my view) as a series of small, short term and discreet functional releases. I can’t really wrap my head around how this translates to project management as I know it; project management still seems to just sit across the top of this process. Just with smaller documents and less paperwork, which doesn’t require agile development so much as force of will to push past the bureaucrats. Project management is already something that you fit to the project's size and complexity. It doesn't need to be redefined again.

However, the contrary view we explored during our conversation, was that if you can call the software development activities a discreet part of a project then it’s management style is part of that process; so maybe Agile Project Management does exist and it's a corollary of the existence of Software Project Management, and that Waterfall Project Management is it's own unique knowledge area also.

What do you think?