Out of Control

Christina asks what to do when you take on a project that is, frankly, out of control.

At the top level you have three options;
1. Quit and go work somewhere less chaotic,
2. Step in and be guided by the people and procsses already in play, and
3. Put aside the day to day busy work and address the key problems.

Let's presume you pick option 3.

I've written about this in the past and my opinion remains the same; the thing to do when you join a project - where the wheels are spinning but nobody's moving - is to start with risk management.

Basically the project risk management framework puts a structure in place for you to identify risks to the project (particularly time, budget and scope) and to get people to help you tackle them.  Especially your sponsor and steering committees.

It works because it is structured and formal and makes the people around you accountable for doing the right thing, rather than just what they were planning to do. It's also a good way to zero in on the critical items that are not urgent but are lurking around the corner - and need to be tackled.

That's the strategy, but in some places it's hard to find the time to deploy it.

So four more suggestions;

1. Get help. 
Pick someone in your team and enlist them in your risk management mission.  They do the paperwork and organise meetings.  You do the leading, motivating and investigating to help get things moving along.

2. Don't be afraid to put other things aside.
There is often scope to drop administrative tasks such as weekly reports, meetings with team members or non critical stakehodlers. Think about whether meeting with these popel is substantially contributing to your project's goals or is just taking up yor time.  Delegate or cancel.  You have more important things to do.

3. Force a rhythm.
If your team are busy but not focused, and if the same applies to you, a quick way of getting things structured  enough to give you breating room is to set a rhythm to your teams work.  Pay attention to the natual rhythm of the project and organisation and set your cycle of events to match that.  Make one of your regular events the risk management activities.

4.  Don't sweat lost time
Often people are scambling to meet missed milestones.  They'll never recover.  Better to admit the slippage and focus on regaining control.  Otherwise you'll just keep spinning those wheels in the sand.

Anyone else got ideas?

(Picture care of Léoo™, CC and Flickr)

Enablers

Today I was listening to a panel of educators discussing where things should be going in schools.  They talked about the concept of enabling skills.

These are the skills that set up a student in their early years so thyey are better equipped for learning in the mid and latter years.  Typically numeracy, literacy and problems solving fit into this set.

It got me to wonderring what the enabling skills are in our profession.  What do you need to know first in able to set yourself up to continue to grow and improve in your role?

I suspect it's not the obvious candidates.

Dear readers - I'd love your comments on this one.

(Photo care of John C Abel, CC and Flickr.)

5/5 - Full Marks for trying!

What kind of people pick up projects midway through? Especially the ones that seem to have all the hallmarks of a failed project right up front?

People like me, that's who. But why? Could it be a desire for stress? A need to stay back and work late regualrly? The love of paperwork?

I wish I knew. Maybe it's a combination of timing and the desire to test your skills. Maybe it's just dumb luck.

PMHut re-publishes (with permission) many blog posts on project management. If you want to look up a concept or idea - go there and use the search tools. If you want to keep abrest of what many project management bloggers are writing about, subscribe to the site.

Well, maybe it was really 4/5.


If you want to know what sort of project I have walked into recently - take a look at this post by Thomas K Casey.  (It explains this post's title.)


Project Management
Business Analyst

Managing people, managing projects

There is a theory (reference anyone?) that management is about planning, organizing, motivating, directing and controlling.

And PM processes are gernally described as initiating, planning, executing, monitoring, controlling and closing.

See the similarities? See the differences? What makes projects special?

Where does leadership fit in to the picture?

Project Management
Business Analyst
Picture by Matt Hintsa (CC) at Flickr

Something old, something new (Requirements again)

Consider your project and its requirements specifications. Are they new and unfamilar or is everybody working within tried and tested boundaries.

In thinking about this issue I have created a model that divides a project into the dimensions of the business requirements (ie processes) and the solution (ie technology.)

These two dimensions frame how familar or unfamilar your stakeholders are with how your project is going to go about it's business. And this familiarity will drive particular behaviours and risks.

For example, if you are using new technology and addressing new business processes you have an opportunity to be quite innovative as you don't have as many constraints as (many) other projects do. Take advantage of this.

If, on the other hand you are dealing with existing processes and will be using existing technology infrastrcuture to solve the problem you face many constraints. On the other hand, everybody knows the territory, so you should be able to work through design, development and validation activiteis quicker than in other cases.

Where does your existing project fit, and how does this drive design decicions, and project management processes?

Project Management
Business Analyst

Photo courtesy of

Peter Forret (CC) and Flickr

Diagram by me

Net Present Value

I have to tell you, this is a topic that I am no expert in. I rarely actually put togther NPV calculations. Usually where I work a finance person will do them rather than a pm.

But I need to be able to explain it to people.

I can explain this; NPV is a way of assessing differet projects over different time periods. It helps pick and choose what goes into your project portfolio. It helps understand whether the project meets the opportunity cost thresholds your organisation has set.

And the calculations themselevs are easy enough once you know how to use the excel NPV feature.

But explaining it still stumps me. This is me having a go.

Someone - Help me out and do a better job.

| View | Upload your own

Project Management
Business Analyst

"Mistakes will be made"

In 1948 William McKnight gave this advice to the people of 3M:

As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative.

This requires considerable tolerance.

Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.

Mistakes will be made.

But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.

Management that is destructively critical when mistakes are made kills initiative.

And it's essential that we have many people with initiative if we are to continue to grow.

(Read about him here.)

I post this because in many projects and in many organisations the game is set up so that you play by a certain set of rules, which in most instances also set you up to fail. Don't be afraid to break away from pre-defined processes and approaches when it's the right thing to do.

You have been hired because of your expertise. Part of your responsibiliy as an expert is to apply your judgement to the obstacles and opportunities that come your way.

And, of course, learn from your mistakes.


Project Management
Business Analyst

Span of Control

Span of control (made famous by Peter Drucker) is a concept that looks at the number of people a manager has directly reporting to them.

This view of organisational structure has two dimensions, which each have strengths and weaknesses.

A broad span (figure 1) means that there is direct communications and interactions between the manager and their many reports (i.e. people who report to them.)

The benefits of this are that everyone deals with the same manager, and as a result everyone is more likely to be aligned with the manager’s vision of what should be done.  The disadvantages are the cost to the manager in terms of time to deal with each staff member.

A tall span (figure 2) means that there are more layers of management between the frontline and the top level management, and as a result there is the opportunity for the vision and communications from the top to be muddied by misinterpretation. The benefits of this model are that the managers all have more time to spend on each person and the work at hand.

Naturally a balance between vertical and horizontal spans has to be found for each organisation, and of course the balance changes within organisations, depending on a number of things such as the complexity of the work, the worker’s self sufficiency and the culture of the organisation.

A couple of examples to illustrate this point;

1. Production line workers typically work in a large worker to manager ratio (say 25:1) as the work is low in complexity and the worker is basically self sufficient.
2. Call centre workers also have a reasonably large number of workers to managers, but this varies depending on the complexity of the role. Simple mass market enquiries (e.g. paying a phone bill) might have staff to manager ratios of 25 or more to 1, whereas complex business to business transactions may be supported by smaller teams with say 10:1 staff to manager ratios.
3. And a bunch of high end business consultants might work in a team of 4 per manager because their work is highly complex.

So, what does this mean for project teams?

There are multiple lessons to be drawn from this concept. And they can be categorised into

• Organising project teams, 
• Identifying and managing stakeholders and 
• Designing future modes of operations for clients. 

And there is potentially some lessons that can be learned for managing requirements.
More to come, but first; Your thoughts on this topic?

Are you 'On Strategy'?

Businesses have strategies.

Most of these strategies are implemented by projects.  If you are doing something that is contrary to, or not aligned with the organisation's strategy, we could say your project is a waste of resources.

Depending on how far off strategy you are probably has some relation to the amount of waste you are potentially creating.

How on target is your project?

Project Management

Business Analyst

How to get the mentoring you need

In this post, Craig talks about how mentoring helps in learning to be a great Business Analyst (BA) or Project Manager (PM). A master-apprentice style relationship is very helpful but if you can't find a mentor, what are the other options?

I think that Craig has hit on a good point. In order to improve as a BA or PM, one needs to see a senior professional in action. The problem is that it isn't always possible to work directly with a mentor. Even in organizations with multiple BAs or PMs there are rarely more than one assigned to a given project. So how does one get quality mentoring when on-site help isn't an option?

The first resource I have found is professional conferences. If you can convince your employer to send you to one of the excellent business conferences out there, you can use the opportunity to make connections with other professionals. I have found at every conference I have attended the speakers are more than willing to talk about what they do. I have never had a single person turn me away during a networking event at a conference and there is a huge amount of information sharing that occurs. I have also had the luck to meet several professionals whom I have been able to stay in contact with for advice when needed.

If you aren't lucky enough to have an employer who will send you to a conference, then you can turn to the internet. Social networking isn't just for teenagers anymore. Better projects is just one of the many excellent resources available on-line to mentor business analaysts. Even a straight up networking site like LinkedIn can offer useful business networking information if you take advantage of their forums. There are yahoo groups that are focussed on specific areas of interest that you can access by email. These resources require a more proactive approach by the individual but if you put forth the effort you can definitely find people to mentor you (or at least commiserate with you on your problems).

While the ideal situation is to have a mentor available to you in a one-on-one situation where they are familiar with your work environment and the people you deal with, participating in conferences and online communities is a not insignificant replacement.

Project Management

Business Analyst

Toward Agile Systems Engineering Processes

I have been referred to this article by Joy at Seilevel. (Care of this blog post.)

Thanks for sharing Joy! I want to read it, but am too busy right now. So I'll put up a link here for you to read.

Let me know if you like it, and if there is anything in particular that grabs your attention.

• Toward Agile Systems Engineering Processes by Dr Richard Turner.

Project Management
Business Analyst

Project Management 2.0

I named a tongue in cheek post a while back “Project Management 2.0.” It was simply a joke post riffing on the power of a good acronym.

But one of your fellow readers challenged me to say what I really thought about Project Management 2.0 as a concept.

My first thoughts were that the whole 2.0 think is in the post hype dip, and I didn’t want to go there, and my second thought was “that would be Agile project management” because of the increased focus on collaboration - which is the hook-up to the 2.0 spin.

And then, in the car this evening, I came up with a diagram that I wanted to share with you that might just be “What I Think” about PM2.0 (if there really is such a thing.)

And it fits neatly and conveniently into one of my four box grids that I like to use.

Over the last decade or three many organisations have learned to trust their experts. Not all are there yet, but the trend is clear; decentralised decision making means more adaptable and viable organisations.

At the same time the Project Management profession has evolved from a focus on WBS, network diagrams and gannt charts into an ever increasing awareness of the business and social contexts that projects operate in.

In both instances it seems to me that we are currently in the middle of the adoption cycle of these two ideas. Most (large) enterprises are aware of these issues and are accommodating them to some degree. And many leading organisations have fully exploited the benefits from them.

(Am I being overly optimistic here? What is your employer like on these dimensions?)

Anyway, without really believing in a 2.0, Project Management and it's context is evolving, and my job is different to the previous generation, just the next generation's will be different from ours.

Viva la evolution.

Project Management
Business Analyst

Scaling and Estimating for Agile Projects

Project Management
Business Analyst

How was your Friday?

How was your Friday?

8.59 Walk onto the floor

9.00 Park at my desk and eavesdrop on developer team not-scrum next to me

9.15 Have a BA advise me on a scope doc for a work package – sign it

9.30 Check with dba on his data cleansing tool; it involves a lite-app with an ugly user screen where they’ll check and modify some dodgy data – I suggest he puts a pretty picture on the screen (nature, dolphins, no, even beter puppies. ) I don't think he buys into the idea.

9.40 Go get coffee for me and lead BA.

10.00 Sit at my desk and wonder what to do with all the emails hat have accrued since lunch yesterday.

10.10 Go for a walk around the floor and say hi to a few of the team members.

10.30 Call three of the team into a room and deal with a boundary dispute – people are disgruntled because of the way the work is playing out. Part of it is my fault for (a) not having published a detailed plan for them to references and (b) for not providing enough oversight – keeping an eye on the big picture. There has been some scope creep. A hard thing to manage as there was no structured goal setting or requirements statement when I joined just a few weeks ago.

11.00 Remind one of the attendees at our little conference they have a meeting with our leading dysfunctional vendor.

11.30 Wrap up the unresolved meeting; more coffee.

12.00 Sit at emails and start filing them- saving a bunch of files to a folder for part of a project review (An 'As is' organisational analysis.)

12.30 Lunch with wife and baby in the park.

1.00 More execution of soft skills, remind people they are valued and loved

2.00 Database design meeting; Agenda: who are the external stakeholders, what design principles should we be applying. Instead we identify trouble rolling versions out to through the various dev and testing environments and try to tackle this issue. We are uilding two applications and have a backlog of versions we can't roll out because of our leading dysfunctional vendor. We also talk about setting up an environment for production support.

3.00 Read over some emails about our leading dysfunctional vendor. Think about what can be done. Have a look at my calendar for next week and wonder how I’ll get the required work done. (There is no plan yet.)

3.40 Take a walk with a develop team leader; talk about what we plan for two new staff who are staring next week.

4.10 Get another call from a key stakeholder for the project review meeting. They don’t have Monday’s session in Outlook and definitely won’t be there. They are one of several with this issue. I try to reschedule. I find a likely time on Tuesday but there are no meeting rooms. I check nearby buildings for rooms. I can book a 200 person room across the road – with coffee and cakes.

4.57 Sure why not. There are 12 of us. It’s booked.

5.05 Leave the building (Friday)

5.30 Get home, dinner, play with child, etc

8.15 Draft a blog post

8.30 Remember my steering committee action for today was to draft a letter detailing our leading dysfunctional vendor’s failures to date

8.45 Save draft blog post. Good night.

Based on a true story!

Project Management
Business Analyst

Picture pinched from Pinky Rocco's blog

which has a piece on stress relief here.

Net Present Value in Excel

If you are like me, doing financial calculations is one of the less fun parts of the job. NPV often trips me up, even though I know what it is and how to calculate it.

Luckily I usually have a finance person double check my spreadsheets before I do anything silly with them (and they always find errors.)

Possibly it isn't me; it's Microsoft who are the culprits.

See this article on NPV calculations in Excel for a breakdown of the way to do it right.

(More on NPV soon.)

Project Management
Business Analyst

Photocare of K8 and

Creative Commons at Flickr

P2M - Japan's Project and Programme Management

P2M is Japan’s Project and Programme management framework.

It’s growing in popularity in Japan, and is of increasing interest to the international PM community for what it can teach us.

I find it interesting that this framework has a much more specific focus on stakeholder and value management that the PMI framework. I have listed their "Individual Management Areas" below to give you a taste of this alternative approach.

If you are interested in learning more here are a few key links.

• PMAJ – Project Management Association of Japan (P2M homepage)
• The P2M introductory handbook (PDF)
  
  
  
  

Project Management
Business Analyst

Punctuated Equilibrium

Remember a few months ago we mentioned Tuckman's 5 stages of team development? Sure you do; forming, storming, norming, performing and adjourning.

Well, here is another view which I think is pretty interesting. It's called Punctuated Equilibrium. (The name is borrowed from evolution theory.)

The basic idea is that about midway through any project type activity the people working on it will see the deadline is suddenly a lot closer and will naturally elevate their productivity.

You can read more on this topic here.

And while we are comparing models, have a look at this one, which overlays the Tuckman's five stages with Gersick's PE models.

The implication for project managers is that a series of smaller, but significant milestones enables project teams to maintain a more elevated performance level over the course of the project than if they are just aiming for the big delivery day at the end of the project.

It's scientific proof of why iterative developments are more effective that one big-bang release.

Project Management
Business Analyst

Deployment Gone Wrong

Here’s a situation:

Your development team has begun implementing a shared enterprise infrastructure. Nobody on the team has ever done this before and they do not take the time to think about how updates will be handled for the software as more applications begin to use it.

The first version of the shared infrastructure goes into production but it is not yet complete. There are enhancements and bug fixes that need to be done before it is fully implemented. Meanwhile, there are multiple applications being written to use the shared infrastructure. All of these projects are running concurrently with the enhancements and bug fixes for the infrastructure.

There are many things that need to happen in order for this scenario to work with minimal problems and no outages for the applications using the shared infrastructure. Off the top of my head I suggest that you need configuration management, a well-defined deployment process that is controlled and repeatable, regression testing before anything is ever put into user-acceptance testing or production, and a well-defined and controlled build process to start.

What happens if your environment doesn’t have all let alone any of these controls in place? The answer is that the infrastructure will fail in a spectacular way at the least opportune moment. Let’s look at what could happen if just one of these controls, such as a well-defined deployment process, is not in place.

If you do not have repeatable or automated deployment processes, you could end up missing steps and having the deployment fail anywhere from subtle to spectacular ways. If your processes are not automated and also not well documented, you could end up with just one person who knows how to deploy the product. This will put you in an at-risk position if that person is out sick or decides to leave. This could also lead to critical deadlines being missed.

All of this will make the entire department look bad to the customer which can potentially lead to cut funding or lost contracts. The problem for me, as a business analyst, is that I am not managing these risks on any one project; I am managing them from a departmental process standpoint.

Therefore, I must document the potential problems from this lack of process in my risk plan for every project. Consequently, I will do things such as make sure I schedule the user acceptance testing at least several days after the deployment to the testing environment. Another mitigation plan I might use is to make sure that I have an escalation plan for deployment problems and that I implement it immediately to avoid last minute issues. Risk management and mitigation can avoid some problems, but it will never offer a substitute for good processes.

Clearly this is not a preferred solution. Rather, a good solution would be to have a well-defined and controlled deployment process to limit the risk involved. The process must be developed from within to get as much buy-in as possible. That said, it must also be enforced from above to ensure compliance by all.

In some cases, all efforts to get the department to institute good build practices will fail. Unfortunately, this means the business analyst or project manager must be prepared to deal with the risk as best they can.

Project Management
Business Analyst

Photo by Nictalopen at Flickr

Project Planning tips

At this time of year there are more than one or two project managers sitting there in front of their project planning/scheduling tool, wondering what's the best way to frame up their plan.

If you are looking for guidance on how to best break down tasks and what deliverable and activities to plan for, take a look at Josh's commentary at ThE pM sTuDeNt.

He provides some really clear and simple ideas that will make your project planning easier.

Here is the post!

Project Management
Business Analyst

OPM3, Project, Programme and Portfolio Management

This presentation is on Project Management and how to get the most out of it, including a look at programme and project portfolio management. I particularly liked the visuals on the differences between leadership styles and roles across the three disciplines.

Thanks to Elmar Roberg for making this presentation available to the world via Slideshare.

If you have questions or comments leave them below. We'll respond as best we can.

(View this in full screen mode to see and read everything clearly.)

| View | Upload your own

Project Management
Business Analyst