The “Business Intelligence Analyst” role

Let's create and train more people to do this!!!!!!

This role understands "the process" of interviewing business customers and creating software.

They can analyze people, data, and processes and create workflows that work, be they on the business or data/software side.

They are high-level thinkers that are senior software architects and analysts that get down to the details of how to make the end solution, yet they get the info from the business (and from their consultant team). They are the glue in the middle.

They know the steps that will have to be made to get to the end of the engagement successfully.

The cost of not having the right consultants is the highest cost of all

Bringing a new resource into a project is expense but sometimes necessary. You might be stuck, you might think your solution will not be good unless you get the proper advice.

The value of a good consultant is very high.

My consulting skill is in Microsoft technologies and enterprise workflow. I can design complex, end-to-end systems that make big differences to businesses. But I, too, need my own consultants. I am not a one-man-band. I need help. I get stuck. I don't know certain things and need experts.

Building your team of experts and consultants is critical. The more challenging your work and scope, the more you'll need good consultants. You might want to hire these people, but you definitely need them. And they're going to be expensive. The good ones will win you REAL BUSINESS VALUE NOW and their cost is worth it in spades.

Just complete the f**ing scenario, already!!

The goal in most projects is to get feedback as soon as possible, meaning time is of the essence. People don't have time to sit around and wait for you; they'll get bored.

So, when you're faced with this reality, working by yourself, don't get mired in detail and "crap" that takes a long time to complete making something perfect. Rather, just finish the scenario, dammit!!

If you're not prepared to do "awesome" work, that's okay. Do your best.These customers will understand, support you and you'll be able to make another (better) product next time.

Don't worry about your demos sucking, their just demos and chances to meet people where you're at.

Are you pair-programming or double-billing?

Hopefully you're doing both and everyone knows about it.

Everyone should know that your output is going to be of higher quality when there are a second set of eyes.

Everyone should know that devs can "hang out" and help each other while also multi-tasking and doing other things.

If everyone knows about these things, then you have a good company and a good customer and all is good. If people question any part of this, all is hell.

Scrum doesn’t fully work without the Scrum Master

You can be an agile team, follow the processes and practices, but if there isn't someone *other than* the dev lead to do the planning and communicating, your project will fail.

One person cannot do everything. They cannot be both the developer, team lead, project manager, business analyst, and scrum master. It just doesn't work. There are too many hats, too many roles, conflicting priorities.

The Scrum Master (or someone other than the people on the hook for deliver and estimates) has to watch the budget and hours and estimates, etc.

Without this person the project and team will fail.

Stepped validation

Process:

1. I interview a customer about what they need
   
2. I share my notes from the conversations with my developer and explain to him the needs / problem.
   
3. I expect the developer to ask me questions and get the job done to *my* liking first.
   
4. The developer reports to *me* now, not the customer.
   
5. I still report to the customer, and the dev to me.
   

I call this stepped validation.

Things that people don’t care about

There are some processes out there that people don't care about or know about. This to me is *scary* territory, but it is also the land of opportunity!

For example, the process of publishing files to a destination is probably well baked but not very well understood by me. I had a situation yesterday were I published "with overwrite" to a destination and the overwrite did not succeed. So now, I am using the more brute method of "delete destination and publish".

In other words, I am doing something sub-optimal because I don't understand the process.

These sorts of areas are the land of opportunity. But when will I / we have time to look into / investigate them?!

If you don’t know how to do it, plan it

If you're on a deadline, don't start what you don't know how to do unless it's the last thing to do.

Know the process, know the data

Two really different things here: the process and its data.

The process is the thing that "works". The data are the things that the working produces (from both its working aspects and non-working aspects).

You can know the flow of the process without knowing much about its data. You may understand how things move and change but you won't necessarily understand what the data MEANS (or its purpose).

The skill/capability of knowing what the data MEANS is that of the data analyst.

The skill/capability of knowing how the data flows and its consumers is that of the process analyst.

Be both but you'll often have to choose one or the other.

Divide and conquer!

Technology = workflow

I learned a new trick at work today that lets me to make better, more complete, more interesting solutions now. I'm stoked.

Learning new stuff is great, but it abounds!

New technology changes the game and the workflow. Typical scenario:

Q: How did the thing/process used to work? What was the old workflow?

A: I don't know and I don't care!

People want new and better things all the time and when they learn them they forget what they never knew.

Projects one day at a time

In project work, the Statement of Work (SOW) is the legal document intended to keep things in order and denote the shared understanding of deliverables between supplier and customer.

Don't update the SOW with each change to the project, only big ones, new deliverables, removed deliverables.

Contract at a high level: Be a service provider and offer your services (planning, development, etc.) on a daily or weekly basis. Charge for the number of resources. Get your estimates right and try to stick to them. Communication change.

Projects don't have to be bigger than a day and a couple of people but often are.

When the job you have is not the job you took

We've all probably taken jobs or gotten into situations—be they marriages, cars, or vacations—that were billed as one thing in the beginning and then turned out to be something completely different in the end.

This pattern is probably the norm in fact.

I took my current job for the money, company, and idea that I would be traveliong between Dublin, Bangalore, Singapore for a week a month.

Fast forward to this job today and I am leading projects but I have not traveled outside of the city and I am mostly doing software development. The pay and the company are the same. I am okay with all of these things but they are very different from what I expected coming in.

So I have a choice:

1. Stay and "suffer" through what I have in front of me (the status quo)
   
2. "Force" things to change internally either by making phone calls or complaining or continuing to apply pressure (also status quo but with a bit more boat-rocking / risk taking) or
   
3. Leave and look for something elsewhere.
   

Those are the three basic choices I think we all face in our lives and jobs every day.

We are free.

Make people make their own assumptions

An important part of leading or delegating work is being able to paint a picture for someone of what they need to do.

Often as managers we don't know what the person has to do exactly but they do have to start so there is something to review! The product can be made "tight" later but first the bulk of the work has to begin. You should be 80% sure what the right product is yourself or you shouldn't have anyone begin. This is the definition of start. (Contrast with Definition of Done in the Agile methodology.)

In general the team *collectively* owns the work. The person doing the work is the knowledgeable and capable one and the on-lookers are able to comment.

Good systems are open and encourage a full review of the entire work product by those involved or curious. There are no egos.

By knowing your assumptions up front or empowering/enabling the worker to make assumptions and then vet/verify them with the customers, work can flow and customers can be satisfied.

Increase your real-time collaboration

Developers are a lot better off when they get to "pair" with peers and analysts who can help them think through the problem and the plan for solving it. Coding is not easy. Learning new programming languages (any language for that matter) is not easy.

Learning languages rapidly should be one of the core capabilities of a programmer: "Oh, you only know one language or skillset / toolset? Sorry, I don't need you."

I'm sure some programmers prefer to read a book and learn the language that way. That's fine but to me this seems slow and tedious and may not even work. Maybe you don't even need that knowledge once you have it. But then again, I'm really not a book reader, I'm more of a doer and web-searcher and like to unblock myself now, when I'm stuck.

Enter the web, books, and peers.

I want to pick a project that requires (or might require) a technology and try to solve a problem with the technology through practice. It'd be nice to have someone that's used the technology to work with me but it's not required. They just have to be a programmer that's willing to learn and be stumped.

This might sound slow and tedious but at least I'm diving in and going for it; and building my network.

Be independent and have positive cash flow

A recruiter the other day asked me what my ideal job was. Not sure what answer I gave them but now that I think about it, what I want to say when anyone asks me that question in the future is two things: A) Be independent and B) have positive cash flow.

Being independent is important to me. It means I am in charge of my own destiny.

Having positive cash flow is also very important to me. It means I am able to survive and that I am not spending more cash than I am making.

I really don't want to have a bunch of ups and downs in life.

10 years ago I was independent and had a positive cash flow. Then I graduated from college.

8 years ago I was not independent and had a positive cash flow. Then I bought a condo, a truck, and went back to school.

5 years ago I was not independent and did not have a positive cash flow. Then I started making better money.

Today I am not FULLY independent (am employed by another company but am working on what I want to be working on and having fun) and have positive cash flow.

My next step is to become independent again and keep my positive cash flow. I hope I can make that happen soon!!!!

You want more senior engineers

Engineer-types can only do so much at once. You want them figuring out how to solve hard problems all of the time. Solving hard problems = making big money $$$$$, you know!!

But once this senior engineer person has named the solution to a hard problem, the engineering team has to come in to solve it indeed. (This costs money and should equal revenue for your organization).

Your senior engineers should be your top sales guys. Everyone else should be feeding business to them. They are probably the bottlenecks of your organization since real hard problems (remember this means real big $$$ opportunities) are many in number and hard to solve ie process!

The cake and the icing

Consumers *will not* purchase products for one of just a few reasons:

1. There's too much icing and not enough cake (relative imbalance of features)
   
2. There's not enough cake (not enough value)
   
3. There's not enough icing (it's boring)
   

Consumers *will* purchase products for one of just a few reasons:

1. There's enough icing and cake (relative balance of features, the holy grail)
   
2. There's enough cake (enough value)
   
3. There's enough icing (it's exciting)
   
4. There's a lot of icing (it's really exciting)
   

All the features and attributes in a product have to be about value INTERNALLY to the producer, but some of those features have to be about excitement and frivolities externally (gotta make that icing and excite the customer!!!). All of this requires work in the end, but some of it is fun and about sales and the customer. Maybe all of it should be fun!!!

Create many teams up front and reap the rewards

In a company where you're compensated based on the number of hours you've worked, you'd better be hungry and prepared to take hours; or you'll go broke.
I've spent a pretty good portion of my week giving my work away to my coworkers by delegating tasks to them and stepping away from the limelight or line of fire on actual work and shirking many of my existing responsibilities. I've gone from consultant to project manager. It's felt pretty good to me to do this and I think that what I am doing is best for the projects, company, and client overall, so this seems like the logical thing for me to do; but it will definitely have a consequence for my pay (not sure right now if it'll be good or bad but of course I hope good!!!).
What I've effectively done is developed business that I can now share with my peers. I am building and growing my team and influence I hope.
Moving forward it's going to be my preference to work on very-early-stage projects and business development activities rather than late stage, well-defined and -baked projects. I don't prefer to be a part of those types of teams. They're too late stage and they've essentially already failed (or succeeded) before they begun due to good chartering and project planning. I want to be a project planner.
I want to *make* the teams. My ideal compensation model will be:

1. Work on early stage analysis projects to pay the bills; be a consultant. Get paid top dollar for this
2. Create highly effective delivery teams to do the work right
3. Sell their work through the delivery; make sure that sales and selling are built in…
4. Make sure that the projects are controlled and delivering well (remember: reputation, reputation, reputation)
5. Let the cycle repeat itself

Create something good together

Do this with your life partner or mate: make dinner, play a game, bake a pie, plan travel and go, have a conversation about something important.

Do this with your workmates: Resist producing things completely on your own with no feedback or shared responsibility. Look for opportunities to collaborate and co-create. Find opportunities to work *with* others. Create a product with them. Learn with them. Don't feel like your time together should be minimized, rather that the quality of it should be maximized.

The process you create is your most important product

It's your legacy in a way. Did the stuff you produced actually last and make a positive impact on the organization as you'd hoped or was it immediately uprooted and removed the moment you left?

When you work in organizational change management and project management, you'll realize at some point that the process you're creating (the outputs of your day-to-day work, the principles you instill, the standards you create, the policies you implement, and the practices you follow) is *the* essential product.

How do you market this product? How do you make this product consistent and continuously improve it? Who are your coaches in it?