It's here Just checked Amazon and the book is now available. You can read pages of it on the Amazon site. It's also available in Kindle format. Barnes & Noble has it as do many other places including Allpm.com where I regularly submit articles.  ¶ 4:48 AM 0 comments

  Business analyst: Best Practices for Success It looks like the book is finally a reality. We're in Buffalo, NY, on a trip that included a few days in Syracuse earlier in the week, and now on our way back home. There we will get our first look at the actual book which arrived while we were gone. The book hits the book stores on November 8, but can be ordered now.
I'm popping over to the other side of Florida on Tuesday for the BBC conference in Fort Lauderdale. It's my first conference of this nature and apparently won't be my last. Hopefully I'll see some of you there.
So I'm celebrating the book's release by starting the new book which is going to deal with being an agile business analyst at the center of the organization.  ¶ 5:25 AM 0 comments

  Is the PM to blame when the team starts leaving? While some might say that the most compelling evidence that a project manager is not doing well or has lost control of his or her project is when the team starts leaving, it is not true. There are many reasons a team leaves regardless of the job the project manager is doing. The best of project managers can only overcome low wages or the attraction of a competitor's higher benefits just so long before the team succumbs and leaves. The project manager may fight with upper management to get higher wages or better conditions to no avail. When upper management believes that project staff is interchangeable their response is "let them go, we can hire more", and the project manager is left with constant churn and deadlines missed. And it may also be the natural result of a recovering economy providing new job opportunities for the pent-up demand of employees who have been dying to leave for years, not just as the result of the current project.

Here's a positive spin on team members leaving. According to Tuckman, the fourth level of team composition is "Performing". Most teams, once formed and composed operate in the "Norming" mode and that is where the project managers wants them to be. Some teams (and I've been on them) move into the "Performing" mode wherein the members of the team pretty much act as one, sometimes to the exclusion of everything else but the team and the project. This is great for productivity and creativity, and the project manager need do nothing but watch since the team pretty much manages itself. The downside is that when, for whatever reason, a member must leave, the team disintegrates. They cannot achieve the same "high" they had while in the Performing mode, and each member typically leaves the team and usually the company in short order. Nothing can be done about it. It's just human nature. And the project manager previously watching the team perform wonders, now wonders what just happened. And it always happens. Sooner or later someone will leave - retirement, following a spouse to a better job, required transfer within the company, etc. The project manager cannot stop the team from sliding into Performance and cannot stop the eventual end, and can only hope the project end precedes the team end.

Yes, blame can generally be placed at the project manager's feet when the team decides to leave en masse over a short period of time without any outside instigation (such as a ten percent reduction in pay across the boards, or a requirement in IT for everyone to put in an additional ten hours overtime without compensation). The fault is usually in not listening to the team. Nothing will chase a person away faster than being not listened to which can be interpreted as lack of respect, a signal that the team member is not important, a sign of project manager arrogance, an indication that the project manager and upper management feels that the workers are just a cut above automatons and can't think for themselves, or all of the above. This condition occurs more frequently when economic conditions are in a down cycle and jobs are scarce so people put up with more just to keep their jobs allowing management to be more arrogant and demanding. When project managers mirror this attitude, they get what they deserve from their people.

Incidentally the definitive indication that a project manager has lost his or her project is when someone outside the project tells the project manager about something going on inside his or her project that he or she didn't know about.  ¶ 2:42 PM 0 comments

  Drowning in the waterfall

During a recent exchange on a business analyst forum, a poster complained that he was “drowning in the waterfall”. Much of the "drowning in the waterfall" is really drowning in paperwork not the process. The waterfall doesn't in itself call for a mass of documentation; the paperwork is the result of the way the waterfall is applied in many organizations. Much of the paperwork that accompanies a development life cycle is not designed to assist or enhance either communication or the development process. It is there solely for control: for management to be assured that certain activities have been accomplished and they have a document that proves it; as a measuring device to demonstrate that phases or milestones in the process have been achieved; as a verification artifact that someone can use to check up on the progress at points along the way; to provide disinterested parties a glimpse at what is happening with the development; to give the auditors proof that the process is being followed; and so forth. Where possible try to turn permanent, persistent documentation into transitory documentation that you can throw away once the document has served its purpose. Write designs on white boards. Do status reports verbally in stand up meetings of no more than ten minutes. Communicate face to face rather than via documents. It saves time. It saves trees. And it keeps your head above water.

  ¶ 4:33 PM 0 comments

  Choices and events When trying to define the solution to a business problem that involves user interfaces it might be profitable to look at the choices the actor makes when working with the interface or the process and the events that occur as a result of those choices.
While many choices users make are no longer conscious - they have performed a particular activity so many times that their actions seems automatic - each entry, action and result in a user interface results in or is the result of a choice the user makes.
Analyzing what choices an actor can make at any given point in the process and the events that result from those choices should constitute a complete definition of the actor's involvement with the process. State charts, event trace diagrams, event-activity matrices, and even use cases are all good methods to diagram the choices and events.  ¶ 3:35 PM 0 comments

  Getting Good Enough In software there is a refrain of "good enough" started most likely by Cem Kaner of software testing fame. Projects can be good enough as well. The problem is to be able to define good enough in a way that everyone - solution team, project manager, upper management, and the customers - agree that good enough has been defined and achieved at project's end. This is done in the early stages of the project by the business analyst if there is one or the project manager.

It is a simple process. Once the problem is defined with the business there are three questions to ask the sponsor or problem owner or customer, whoever you are dealing with having the authority to answer the questions:
Is this the problem you want to have solved?
How are you going to know you solved it?
What do you need to see to prove to you that we solved the problem?
The answers to these questions are not difficult and constitute the acceptance criteria for the project. The answers also create an informal contract between the project team and the customer: when you show me that the problem is solved, I will sign off.

The answer to question one confirms that the project is tackling the right problem, the solution of which the customer or sponsor is willing to pay.

The answer to question two establishes the acceptance criteria that proves the problem has been solved to the sponsor's satisfaction.

The answer to question three establishes the acceptance test structure - what we are going to do to show the sponsor that we have successfully accomplished the answer to question two.

Getting the answers up front before development has started keeps all the "how hard would it be to..." and other addenda from sneaking into the acceptance criteria. The acceptance is focused on solving the problem as stated and that is all.

And that is good enough.  ¶ 6:25 AM 0 comments

  Agile Planning For some, the agile movement represents an anarchistic reactionary approach to software development and management in general. They see no discernible planning process and cite the Agile Manifesto's statement that "responding to change" is preferable to "following a plan". The Manifesto and related materials say nothing about rejecting planning, only that the plan must be flexible and responsive. In Extreme Programming, a method endorsing self-organizing teams without project management, with the focus on such rapid development of software deliverables that planning seems to be a detriment, each iteration begins with what is called the "Planning Game" in which developers and customer meet to plan what is going to happen in the next iteration. In fact, all of the agile methods include as part of the process a planning session. The primary difference between the agile approach and traditional project management is that the agile approaches all include the entire team and the customer in the development of the plan, and most methods make that plan publicly viewable. All project management approaches state that the plan is a document that proves that planning has been done, and it is not written in stone. Upper Level Management wants the control and comfort of seeing a plan followed exactly and without variation. This is an issue of upper management, not the PMBOK or agile methods. Agile approaches simply state clearly and loudly that plans change. The methods make that change part of the process. Change is forced with every iteration or sprint completion whether successful or not. Upper Management buying in to an agile approach accepts the environment of constant change and realizes that an iterative, incremental approach to project management is the only way to accommodate that change.  ¶ 4:51 AM 0 comments