"...listen to things that are tough to hear, and say things we don’t think will be popular"

I could not agree with this more. Difficult feedback from others must be considered an open window into how we are perceived. If you slam that window shut as soon as a foul odor wafts in, you might never realize it's being emanated from you yourself. One, in my opinion, can only improve so much without the perceptions of others to use as an external view and to match up against an internal compass.

Thanks!

Excellent post Jonathan! I'm printing this out so I can start asking these questions of myself to bring some improvements forward.

Domain knowledge is an interesting entity. I've always been a firm believer that a good analyst can analyze anything and domain knowledge is a luxury. However when interviewing and hiring, knowing that a candidate has some expertise in one or more of these domains is an important factor in making a decision on which candidate provides the most value.

As I've proceeded through my career, the above sentiment has begun to change, too. I'm more and more placing importance on having some previous domain knowledge in business/technical areas as a prerequisite and obtaining some crucial to my growth as an analyst in my industry, but also one that can migrate into other vertical areas.

Appreciate the insight!

Doug

Well you've covered "Why?" darnit. That is my all time favorite.
My other questions that I really like stems from the book, "The Goal" by Goldratt. It's simple: "What is the GOAL here?" This question is very similar to your #1, but there is no direction or emotional additive to the question, like pain, profit, reason, etc..I want my audience to define that on their own.

I should point out that I do not ask what the goal of the project is at first. I simply ask what the goal is. I have found that by segregating the two allows the audiences to think better about what they are trying to achieve at a high-level. The follow-up question is "What is the goal of the project?" This one serves two purposes: first to link the original goal to the project goal (or to discover that there is no link) and also to dig a little deeper.

These two questions produce two simple statements that get documented, published, printed, tattooed, promoted and plastered everywhere I can. They help keep the focus where it should be, and when the conversations in JADs get tumultuous....I always come back to them.

How do companies in multi-project environments with personnel limitations maximize the benefits of team work even when some key personnel must work multiple projects at a time?
This is the situation that I work in and have found that the teams that have a structured and defined communication plan are much more able to focus and refocus from one thing to another. The relaity of multi-tasking team members is that there is a degree of difficulty in jumping from one thing to another and certain amount of ramp up time occurs when switchings gears. What proves to be helpful is coordinated communication, both verbal and written, that allows these resources to make the jump as smoothly as possible. This revolves around active and passive communication. Active involves pushing information to the multi-taskers to keep them updated on the critical things that they will need to address. Communication of expectations, needs, direction, and other things that the team is dependent on them to do is critical., as these are the actions that they can attend to from a running start. Passive communication is generally a notification of statuses and other updates, as well as direction to "go here for for more information", which can direct themto documentation and diagrams to help them stay updated.

Are project teams really that bad?
I think that project teams are fine, and I understand the value of keeping teams together to enhance cohesiveness and the like. I think, though, that I'm more of a fan of task force type teams, especially when the resources on them are all part of a larger group that works on the full spread of projects. In these situations, there's always some sort of a running overlap of knowledge building as personnel move from one project to the next while under the same overall umbrella. So for me, task force teams tend to be more focused, less complacent due to stagnation, time and comfort and more sensitive to the things that are not in place, like specific knowledge that must be acquired to get something accomplished. Just a personal opinion.

What are some indicators that you may be reaching the point of needing to break up a team that has worked together well for quite a while?
I would look for patterns of failure or partial failure like missed milestones, poor time and organizational management, scope creep, verbal bantering and bad attitudes.

Thanks Jonathan

DougGtheBA

Hey David:
While I agree with "the only customer that counts is the person or organization that is buying the products/services your whole company offers" per your post, the reality is that many IT orgs don't have direct access to external customers. We rely on the portions of the organization that we can provide direct value to, e.g., sales, marketing, etc. I don't see this alignment issue as treating one portion of business more as a customer than the other; it's a matter of removing barriers no matter who we work with on the business side.

Alignment of IT/Biz cannot solve the world's problems, but we can make an exceptional difference in the ability of internal business to be able to function with external business, thus generate more revenue. All it takes is a change of mindset many times and the willingness to also change the way we actively interat with our partners.

Feel free to mooch when you're ready. That's what they are there for, and I hope they help

What an enlightening thread that was. I posted direct comments there, but I want to thank you for bringing the whole thing to light. I missed the original post. The theory presented by John Ownes has really thrown me for a loop, and I really want to know about what drove him to the point he is at.

Imagine the cost savings achieved by removing the As-Is portion and just digging into the To-Be. Definitely worth researching.

DougGtheBA

Yes absolutely I've gone through that....sometimes as soon as the end of the project while doing a review. To compliment the others' comments, I guess I'd just add that none of us are experts out the starting gate. It takes time to craft anything good, and that only comes via experience and practice. Whether "good" describes simpler, more concise, more detailed or the like is irrelevant. It's just that one must start off somewhere, screw it up a few times and learn from those mistakes.____The one thing I've noticed with myself, is that I really need to force myself to look to the rear in order to teach myself how to better my capabilities. This is an active exercise, not a happenstance encounter with my previous work. As such, I find the rewards are greater.____Best Regards__