Team Clock

I've got a friend from high school. Steve Ritter is his name.

He came over to my house a while back for a guitar jam and blew out the room. Haven't heard hide nor hair from him since. I don't think the rest of us were all that bad...

Now, in the wake of his "I don't usually play acoustic" (he has a $2500 Martin, I'm not stupid, Steve, just tome deaf) and doing electric riffs on heavy acoustic strings- the only thing I had going for me was my writing skill. I knew I was a better writer than he is. Had to be. He was in the plays while I was on the newspaper, yearbook and radio station.

Steve tells me he wrote a book, could I review it?

Sure- just had unemployment (ethics requires me to purchase stuff I review, especially from a friend) and getting used to a new job  kinda delayed it.

Here goes:

Turns out the SOB is also a better writer than me.

Bastard.

Now I have no reason to live.

Seriously, though, Steve's book is titled Team Clock: A Guide to Breakthrough Teams.

Steve took the old group communication model (he uses the psychological version, which is the same goofy storming and norming, etc.). But Steve made almost the same leap Maslow (you remember- 'self actualized' and 'hierarchy of needs') made in the 1950s.

Team Building (communication) is a continuum, not like the seven steps for grieving.  Ritter uses the face of a clock for his model... and the walks you all through the complete life cycle of a team. Any kind of team.

If you are a Project Manager, a Scrum Master, a Portfolio Manager, a Business Analyst or an Architect/Lead Developer, go buy this book.

All that PMI crap about inputs and outputs are nothing compared to what Steve's accomplished in 88 pages. And you don't have to memorize a thing.


There are direct application (pun intended) for software development teams.

Those just getting organized.

Those ready to take the plunge into Agile methods.

Those who's lead developer is now working for Google and pretty much everybody on the team thinks it's great, but why did she get the job and not me?

Oh, sure, if you need some help, the Team Clock Institute is standing by with operators waiting to take your call. i think they take American Express. And, yeah, if Steve and his colleagues are half as successful with your issues as he's been with those who confirmed his theories, you're going to wish you called him a long time ago.

But if you want to know (you PMs and BAs need to know this stuff a heckuva lot more than memorizing that certification drivel) how to motivate and manage your team. This book will explain. If you can help push your team out of the comfort zone into unknown or untried region- Steve has an outline and an example for you.

It's not a How To book. Steve wrote a Think About This Way book.

If my team was having major issues or I couldn't deduce what the problem was, I feel confident Steve and his team would find me an answer and a method of 'fixing it' or at least understanding it.

Team Clock is not a panacea. In fact, Steve mentions that there are times team members have to leave. But unlike goofy management books like The One Minute Manager, Ritter wrote a book that I can use as a team member and a team manager for years. Not many $20 investments can say the same.

Now that's out of the way:

Steve:

1. When did you become such jock?
2. You're killing me with three syllable words- there are perfectly good single syllable words, amigo: it's u-s-e, not utilize and t-i-t-l-e, not entitle (entitle means having a right to something). There are a couple others.
3. I'm just yanking your chain- you did a fabulous job. Very little psycho-babble and right to the point.

Now. How do I sweet talk him into our band?

Enterprise Architecture: Lincoln Logs for IT Folks

It's been a couple of weeks and everything seems to be going well.

I'm working with an Enterprise Architect. As a sort of junior architect. The boss calls me a Knowledge Management Specialist since we're working on cool stuff like search engines, wikis, knowledge capture and knowledge dissemination. The gig's pretty high in the food chain, but I haven't stepped on my di....um....made a major mistake yet. 

Relax. I didn't know what Enterprise Architecture was, either. And no, you don't get to design and build large companies in an artistic way.

It turns out, Enterprise Architects are like BAs, but on steroids.

They ask the questions when someone in a large organization wants to add, improve, replace or remove something. The architect makes sure the IT organization's standards are imposed on new projects at conception. The architect thinks and plans how new technologies will or will not fit and how to scale applications into usable tools. The architect makes sure the data is sourced and accurate (Oracle and SAP anyone?). And that everything is properly licensed, copyrighted and implemented.

The architects shepard projects through the minefield of IT Governance (that's big time talk for who's in charge of the 'puters).  After the Architects get the major questions answered, they 'architect' the project. How does it fit into the mix of applications? Where should the database go? What kind of data base should the application use? How do we get the data from point A to point B. Document it. You get the idea.

There are Data Architects, Information Architects, Application Architects and Content Architects. There are probably other Architectural Types I haven't met yet.

The big difference between an Enterprise Architect and a Business Analyst is that as a BA, I was only worried about my project and how my team got its stuff done. This is as it should be.

But suppose the organization has 60-100 project going at any one time and a third of the BAs are like me? You know, Pragmatic and Focused so my boss looks good. Everyone would be pushing his or her project or portfolio. A mess. A chocolate mess (to those younger than Boomer age, that's how M and M Mars used to advertise M&M candy).

On this side of the Project Management Office, we're looking at how these projects support IT plans, objectives and how they fit into the mix of stuff already available. We got that information from the business. Because the business pays our salaries. And we like our salaries. The words 'align' and 'alignment' are used a lot. Align means do it the way the business needs it done to impact the bottom line, not the way you think it should be done.

So the boss wound up the key sticking out of my back (you know, where the recruiter and HR knives went in?) and set me onto five projects. Knowledge Management Projects (I feel like Bill Murray's character in Stripes when the General asks him what kind of training his platoon completed). Short leash (heck, it's only been a couple of weeks) but fun as all get out.

I'm drawing diagrams in VISIO, I'm writing up Business Rules. I'm creating project plans in Excel (having taken the Project course this spring, I'm sticking with Excel until I have to turn out a plan in Project- there's so much crap in that program you never use, it's results are counter intuitive and you can't adjust the defaults- and don't get me started on task numbering!) and having a lot of fun talking to Subject Matter Experts and Stakeholders.

See, I did a lot of KM back in the day. Much of that stuff had to be created custom in the 90s because, at best, folks were collaborating on NetMeeting. Word Docs and Spreadsheets floats around the world. We didn't know from WebEx, GoogleTools, Open Office, Instant Messaging, Twitter, Tweeting, Twisting or Twining.

That's changed. And it's an exciting change. And that's what we're gonna see: How Scot adapts to the Enterprise View and Knowledge Management 2010.

Tune in again, friends. Same Bat Channel. Same Bat time! (for the younger than Boomers out there- that's how the TV Series, Batman, used to sign off on ABC. Jeez, doesn't it suck to have a joke explained?)

Discovery Zone

I interviewed with an attorney this week. Her company dumped what might turn out to be a major IT project in her hands. She talked to one of my best friends who recommended she talk to me.

The first phone call was frantic... for the attorney and for me. As is typical, her mind was down at the field and controls level and I had to a. figure out what she was saying and b. make it look like I knew what I was talking about.

After about a half dozen questions, I realized where she's at and why she's in trouble.

This company gets sued a lot, I guess, there are a lot of in-house attorneys and, to use her words, "...hundreds of Outside Counsel."

Legal Discovery

Unfortunately, the legal profession uses the same word we IT folks use when we start a project: Discovery. Seems that in a civil lawsuit, Discovery occurs when someone sues someone else. Both sides have to give copies of relevant data (documents, spreadsheets, e-mail, etc.) to the other side. Turns out my new friend's company does this manually. In this day and age!

Thankfully, the company is throwing some resources her way and we may be able to solve her problem.

The company is adding some enterprise tools- but these tools aren't connected to anything in the current plans. Yep. No data store, no way to search, no history of use, no ability to browse using a taxonomy and no way to create and send a digital package of documents/data to opposing counsel, much less e-mail confirmations and an audit trail.

So the poor lady has two problems: where do we put all the nicely tagged and redacted data items and once they're there, what happens?

She has 3 Terabytes now. How do we get disparate databases connected (including non-company hosted systems) and then once all that stuff is properly stored in a data center somewhere- how do the other attorneys find and use the documents.

She was mostly concerned about the data store and what she kept calling "the index." She's right. The search engine needs to be able to pull records based on a lot of metadata. At least the metadata tagging will be automated!

Her IT Department has no resources to help her. Its been ravaged by lost and unfilled positions caused by the economy and several company reorganizations.

No wonder she was going nuts. Heck, if I was facing that and didn't know anything about content management, data mapping, batch ETL (Export/Transform and Load. No? It means connect all the databases and make them work nicely together) and the ways and means of attacking and solving the problem (project management and business analysis) and designing a solution (at the abstract and the wireframe levels, certainly), I would have been much more upset than she was. Hey, I can't write a brief or represent someone in court for money...why would her company expect her to be able to do what I do? I don't.


IT Discovery

Here's what the Project Discovery Phase looks like from my perspective- the Business Analyst:

The goal of this phase is to find the new system's boundaries (this will help define the Scope of the project), gather and organize functional requirements and settle on technology and architecture. Once the deliverables (the stuff I hand the client when that part of a project is completed) are in, the customer/company/client then has enough information to intelligently deal with how it wishes to proceed.

I advise and suggest while the company does everything except figure out how to pay for it and decide whether its going to do it. I guess they think that stuff is proprietary and private. OK by me.

I'm a sort of combination resource-subject matter expert-adviser. The Project Manager (if we have one) and I are what's called 'client-facing.' This is a silly term for: we talk to the client/customer.

I usually go in with a Project Manager (if we have one) but much more importantly-- a really smart technical architect or Lead Developer. We grab as many Word Docs, Excel Spreadsheets and paper, passwords, user ids and network paths as we can.

Then we sift and read. I then draw what the company is doing now (called an As-Is Decomposition)  and a proposal for automating one or more processes (called a To-Be Decomposition). The architect and I are beginning to design a possible solution. I start setting up interviews or meetings so I can ask questions and define the high level requirements. The architect is doing a parallel study for the technology (development languages and basic coding standards) and architecture (identifying the likely service layers and a beginning of the database table design).  We constantly confirm and reconfirm the validity of the existing process and what the stakeholders tell us the business needs (business rules).

I write my functional (functional - that means a description of what it does, not how it does it) requirements, a few fancy pictures (remember I told you Technical Writers to always have one graphic in color in anything you write that's more than two pages? The company folks you're working with need as many diagrams and pictures as possible top help them sell the project- preferably in color).  I usually add a couple of 'artist concept' wireframes of a basic interface and a lot of diagrams. 

The architect is writing up his/her technical document. If it's going to be written in .Net, there's a lot of cutting and pasting from the Microsoft Development Network website onto our wiki- I never watched where the J2EE architects steal, sorry, borrow their documentation from but I assume its on the Sun site somewhere or maybe at SourceForge.net.

I then edit the technical document because I have yet to see a developer, even at Microsoft, who knows how to write. I'll also help here with any diagrams or flow charts the architect wants (which I 'suggest' forcefully, see the parenthesis two paragraphs up).

From these two documents (and maybe a Business Case), the company can count function points, bid the project or put everything on hold. Hopefully, the last option doesn't occur because I usually....no...always need the work.

For some unknown and mystical reason, my company gets the contract for the Functional Requirement Document I just wrote. every time. How do you like that? Amazing streak of good luck, no?

My new friend wanted a proposal in plain English. This sparked friendship. I hate lousy writing. But she wanted complete explanations. So I spent most of yesterday evening and this morning writing it. It was seven pages long. I thought I went overboard. But my original friend said I didn't so we'll see what happens.

I think the two color flowcharts and the lovely Activity Diagram will help, as will the seven PowerPoint slides with animation and reuse of the graphics.

I ain't no dummy.

Stay tuned. Let's see if the winning streak continues.

Powered by ScribeFire.