Search This Blog

28 September 2008

"we can't build this, not on our budget"

People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.

This is frm a story you should read. It is at Stevey's Blog Rants.

It is definitely one side of a story.  If you have a response I'm looking forward to reading it below.

27 September 2008

The Project Management Process # 8 - Conflict Management

This week we look into conflict. What causes conflict at work, and in projects?  And what strategies do we have for managing it?

If you only leave with one point, remember this; Nobody likes surprises so don't hide bad news.

24 September 2008

Work experience for graduates

Hi readers,

A quick note for anyone in the Sydney, Australia area.

I am trying to arrange some work experience for some talented Masters of IT students I have been working with. Most of the students are from the India region.

If anyone out there can assist by providing some work experience - from a couple of weeks to longer, I'd be keen to hear from you.

Alternatively if you are interested in hiring some juniors, I have a bunch looking for their first Australian job.

So, Sydney, if you are looking for programmers, analysts, project assistants, dbas etc. I'm your man.

Photo care of Etolane, CC and Flickr

23 September 2008

Past Septembers

Sometimes we bloggers get very busy at work.

This is one of those times for me, but in order to keep the content flowing here are some of the posts I look back on and find interesting from this month in the past.

For your information, I started this blog back in 2005.  In September of 05 I was having my first thrust at blogging regularly.  The themes I was writing on at that time were quality and scheduling.

Two posts that I think are worth revisiting are;
The first was an article on a nice quality management tool I use - Servqual/aka RATER.  It was also my first Wikipedia entry.  As project people we mostly deliver intangibles.  And so taking a service provider approach to quality can help us keep our clients happy.

The second - Global Competency standards was about separating out basic skills and advanced competencies.  I linked to an academic work proprosing tiering projects by complexity and identifying the different skill sets that each category requires.

As you can imagine - a small 8 week website development is a little bit different to a global supply chain project.  And just as the applciations are miles apart, so are the skills needed to manage them.

While I look back and see that the quality of my writing has improved, I still think they are both intresting and relevant.  Go take a look and tell me what you think.

Photo care of gunthert, CC and Flickr.

21 September 2008

Peace one day, Sept 21

Non-technical BA

In the comments to this post, Andrew asked if there was still a place for a "non-technical" BA. I would suggest that "non-technical" is in the eye of the beholder.

My career has gone like this: programmer - database administrator - project manager - software engineering manager - business analyst. I suppose you would describe me as a "technical" BA. However, that doesn't always help in business process modeling. A lot of times you need someone familiar with the subject matter to get in and figure things out.

This is where I have to ask what do you mean by "technical"? An accountant who becomes a BA is still a subject matter expert (SME), but not a technology SME. Where is the line between technical and non-technical? Does technical have to mean IT or can it mean any area of expertise?

In this post Craig references an article about the Business Analyst vs. Enterprise Architect (EA) smackdown. The author makes an effort at identifying the differences between the two roles and quite frankly sounds to me much like the argument about a "technical" BA (the enterprise architect) vs. a "non-technical" (the business analyst) one. The article talks about how the two roles are complementary in their functions. The BA is primarily concerned with business value and business context while the EA is primarily concerned with defining the technology to use to solve a business problem. This view makes a lot of sense to me.

While it is relatively easy to be informed in multiple areas, it is difficult to be an expert in multiple disciplines. I see no reason a BA could not come from the business side of the company and work with an EA to find technology solutions to the problems being faced.

If you can’t have both a BA and an EA, the one you need in your team will depend on other factors such as business experience of the rest of the team, how specialized your industry is, and whether you have a good technical resource who can work with a business focused BA or not. Having said that, it is still my opinion that a BA should understand the technology that is available in order to understand how to maximize the business value of a solution.

As Craig mentioned in the comments to the first post, a business analyst should be focused on exactly what the title sounds like, the business. Whatever their second area of expertise is, they must primarily understand the business and the tools that support it.

20 September 2008

Adaptive is not the opposite of planned.

Glenn agreed with me on the idea of planned and adaptive being two poles on a scale. Funnily enough this caused me to reassess the idea.

Planning is indispensible, plans are useless. Plans that don't accomodate change are stupid.

Are you stupid? I didn't think so. (You are reading this, after all.)

So what is the opposite of adaptive? It stikes me that the answer is stubborn.

I need to re-do my model. And with planned now freed up I think I'll apply it to the Y axis. Opposite of planned = unplanned.

And now we have another think about where Agile methods come into play.

Glenn? Other readers? Thoughts?

The Project Management Process # 7 - Managing people

This week's presentation is on managing people.  What motivates team members?  What types pf personalities dowe have in project management? And what's the difference between managing project teams versus operations teams?

There is a section in here on the Myers Briggs personality type indicator. It's based on an article at Max Wideman's site. You can read it here.

19 September 2008

Agile projects and the project context

More discussions about the suitability of agile approaches to projects.

My investigations and experience suggest a stable environment doens't so much need to approach projects with an adaptive method. One the other hand, when your project s operating in a dynamic environment, being adaptive seems sensible. Especially when there is a time to market pressure.

One of the significant differences between effectie agile organsiations and tradtional ones is the orientation to process or product management. In fact - nce you start looking at an agile approach to portfolio management the development strategy even moves away from projectised work.

This seems to me to be strongly related to the concepts of SOA and enterprise architecture. With these models in palce a lot of analysis is done for you. It is much easier to know what and how to build.

Comments welcomed!

16 September 2008

top 100 lists

So it is usually nice to be recognised and today we were on the blog.  Jurgen at the blog has produced a list of the top 100 software development management blogs.  It sure is a niche world out there.

It's an interesting list with a combination of industry stars, the bloggers I interact with (and read) on a regular basis, and a bunch of new people who I will defintiely check out.

Are you looking for fresh perspectives?  Take a look.

Why don't you start your own blog? Share your experiences and perspectives with us as you learn your trade?

And where did we come? Ranking doesn't matter so much as being nominated and included (i.e. not top 10.)

Thanks Jurgen.  Here's your link back :)

13 September 2008

The Project Management Process #6 - Leadership

Hello people! This week's topic is leadership.

Midway through this pack I refer to another presentation where a bunch of practitioners discuss the differences between management and leadership. I published that presentnation yesterday. It is here if you want to browse through it.

12 September 2008

Management and Leadership

In the spirit of social networking and learning together the people at Linked2Leadership put up a question at LinkedIn and asked "Management v Leadership? How do you see it?"

Below is a presentation of 162 answers they received. It is prefaced with some theoreticians' views and makes for an interesting read.

It's relevant to you as you are a leader in your project based workplace.

So, Management v Leadership; How do you see it?
Management vs. Leadership - Linked 2 Leadership
View SlideShare presentation or Upload your own. (tags: tommyland keynote)

10 September 2008

Business analyst versus Enterprise architect smackdown

Take a look at this article comparing Enterprise Archiects with Business Analysts.

Which team are you rooting for?

Link: The Business Analyst versus the Enterprise Architect

Thanks to Andrew for sending the article to me.

(Photo care of Okinawa Soba, CC and Flickr)

9 September 2008

The August Survey; Business or IT?

I'm a curious fellow, so I asked you whether you worked in the business or IT side of the technology gulf.  Here is how the answers came back;
  • 98 people responded.
  • 34 of you are 'business' workers
  • 55 of you are 'IT' workers
  • and 10 of you are students.
What does this mean?  What is the difference between IT and business?  In general, are business people ignorant about technology and are the technology people in the dark about how business runs?  Is this you?

It keeps on surprising me when I come across the people who choose to remain ignorant of their tech/operations counterparts in the organisation. 

If you are in the IT team, the business people are your customer, so you really have to get to know them, and know how and why they work, to be able to effectively deliver good outcomes.

And if you are in the business, you need to know your tools.  Can you imagine a carpenter or plumber that doesn't know their toolkit inside out?

In particular, we project workers need to understand both - at a strategic and operational level.  We are the ones who create the business of the future through the day to day priorities we choose, and the design decicions we make (often based on time, money and other contraints.)

So we especially need to understand the consequences of our actions.

Do you? What are you doing to keep learning?  Share your wisdom with us here.

(And hi to the students who have been coming by!  Nice to have you here.)

7 September 2008

Herding Cats

It's what we do.

You might be more familar with Herding Cats as the name of Glenn Alleman's excellent project management blog.

6 September 2008

the project management process # 5 - Marketing

So, what do marketing and projects have in common?

Firstly, marketing is a customer centric way of looking at business.  Secondly it provides you with a handful of frameworks, taxonomies and tools to better understand your customer and to model products.  And thirdly, it's a way of managing a shrinking scope and growing budget and schedule!

Marketing was the focus of my first degree and shaped much of the way my career has developed. It seems to have had a positive effect for me.  Have a look at this presentation and see what you learn.

5 September 2008

Project Cost Management

Last week I published a presentation from Slideshare on Project Schedule Management. It is a dense and PMI oriented approach to planning and controlling your project scheudle.

There is a companion slide pack on cost mangaement by the same author.

Just like the last one, it's full of solid content.

This one is shorter.

The thing that caught my eye was parametric estimating; which is essentially using mathematical models to do your estimates. Think this; if one unit of work costs $1.000 then 10 units of work should cost $10,000. Simple, but with the obvious potential for elaboration into vastly sophisticated models that I couldn't comprehend.

Project Cost Management
View SlideShare presentation or Upload your own. (tags: earned evm)

4 September 2008

The Carnival of Project Management

You might remember the series I was posting "The Carnival of Business Analysts" which was a selection of blog posts from around the world on a series of BA themes.

Go back and check it out if you are interested. The Carnival of BA topics I coverred here are listed at the bottom of this post.

The purpose of this post, however is to draw your attention to the Carnival of Project Management, which is usually hosted at Elizabeth Harrin's blog.

If you have a PM blog you can submit an article you want to promote and she'll publish it for the world to see. Or if you are a PM and want to read what PM bloggers are saying - go take a look. A lot of the content is right off the beaten track, so there is usually something brand new for you to investigate.

Link: Carnival of Project Management

And the Carnival of Business Analysts

2 September 2008

Recruitment drive

Hi reader,

I hope you have enjoyed this blog.  I was hoping you culd do me a favour.

Would you mind sharing this site with three of your friends who work on projects.

In particular I'd like it if they were from the not IT side of the game. The idea there is that the business folk are typically less trained in how project work and could find the site particularly useful.

But really, anyone you refer would be very welcome.

I am hoping to increase the number of RSS and email subscribers in partcular, but the bottom line is I want to increase visits to the site.

Photo by Slice and CC at Flickr

1 September 2008

Project management ethics

Here is a real scenario that you could face.  How would you handle it?

You've won a contract to do a multi-million dollar project for a US DoD agency.

Your team is a team of excellent project and software professionals who have worked together for several years and consistently beaten the odds delivering high value solutions on or very close to budget and planned times.

You are based in Australia (or Canada, France, Germany, Brazil...) and in your country it is illegal to discriminate against staff based on their race.  Racial discrimination is anathema to you anyway, as you are looking for the best and brightest and your experience is that race has nothing to do with talent or motivation.

So you wouldn't think for a moment of getting rid of Johnny Tran, you ace security expert, born in Vietnam, but who moved to your city at age 2.  Or Sara Kahn, an excellent data analyst who moved here six years ago as a refugee from war ravaged Afghanistan.

But now you have a contract that requires you do not employ people born in certain countries due to US security concerns.

What do you do?  Let Sara and Johnny go?  Decline the contract?  Break the law?

The answer for some agencies in Australia has been to apply for exceptions to the law.  Is this an ethical response?

(I guess this is the industry that builds killing and maiming devices in the name of making the world a safer place.)

So project people.  What would you do?

Inspiration for this post was Background Briefing at