One many, many one

As a project manager on a single project, I will not go as far as writing the code. It is too much to manage the project and to be on the hook for producing the product, you have to separate these concerns! I must manage the project only and employ others to do the main work.

When someone else is the project manager on a project, I am happy to plug in and write code / do work / take direction. Great.

In my opinion, in organizations, people need to own things and they cannot own both the project/business side AND the code/delivery side AT THE SAME TIME (for a single project/account).

I do think it is possible, however, to be both a project manager/owner on one project while simultaneously developing code on ANOTHER project as a team-member (non-manager). I think this is an ideal situation to me, where I can do both. I get to play with technology and be a developer/producer, and also be a manager. I can improve skills at both at once. No need to pick, it's not one-sided!

How low will you go?

In project management—I think—you can go all the way down to the level where you're doing all the work and writing all the code. But can you really "manage" the project if you're in it? Probably not.

A coworker is making me think about how low I will go on this. Will I write code? Will I talk to the dev team about the solution? Will I design the solution? Maybe as long as I REFUSE to write code, I'll be fine. That is high enough level and I can insure that others and not me write the code and produce the project. I have to stay high-level and be a manager, not a doer.

The sexy parts of project management

It's not the work, it's the people, results, client, technologies, and knowledge.

Much project management today is focused on the BORING (and hard) part of project management: the work. The work is fine, it's hard, it's there, it's complicated, but it really doesn't matter if you can't market your WORK PRODUCT. Your work product is your results; what you accomplished, what you produced, what you changed, learned, did. It's the end and the journey.

My proposal is for a new view of project management that is MARKETING focused. I want to think about and share the SEXY parts of project management like the people and how smart they are, the client and how cool it is, the industry and how interesting it is, the technologies and how cutting-edge/cool they are, and the results and how awesome and game-changing they are.

There's a way to do this and I want to start the wheels in motion on it ASAP.

Make the budget last

Many things in business are fixed-bid, not time- and materials-based. Sure, it's lovely when you're in a situation that you can charge the client for all reasonable time, but this isn't usually the case.

Right now, I'm working on a fixed 80-hour budget that will have to carry me into Jan 7. I've spent almost all of the hours so far, as this is my only project and I'm pretty much full time on it. But what's reasonable to bill?

I have to think about what I have to complete (a statement of work and technical spec and a couple of days of meetings with the client) and how much time that will take (~20 hours). So I think I'm only going to bill for 20 hours this week so I can bill for 20 the following week to fill the budget. This makes sense to me but is kind of "weird math".

Plan, Present, Collect, Transform

I'm starting to see a pattern emerge in data collection and information systems: plan, present, collect, transform. Let me explain.

Planning is the stuff you have to do NOW or before you get started.

Presenting is showing the users data.

Collecting is getting data, either from the users or other data sources.

Transforming is using the data you have to manipulate it. This may result in a new presentation or a change to your model (and views).

Extract from database or from users? There’s really no difference…

Whether your're writing a package to pull data from a database, or a web form to collect data from users, you're doing the same thing: getting the data. This is all part of the "E" in ETL (extract, transform, load).

I wrote last week about the similarities between SSIS and Windows Workflow Foundation; they're really similar in my opinion.

When I'm working now, I'm starting to "bucket" data collection tasks (be they user-facing forms or databases) into the same category. I think this is helping things out, architecturally.

What are your experiences with this?

Workflow foundation: new capture. SSIS: existing capture

Per my previous post on the two faces of business intelligence, I'd like to further my point by describing two "core" technologies from Microsoft: Windows Workflow Foundation (WF) and SharePoint Integration Services (SSIS).  These two technologies in my opinion are "big" in the sense that that "orchestrate workflow".  Let me explain.

Windows Workflow Foundation is a technology that allows a developer to "map out" a business process and wire in the user scenarios to capture--and then store--the data.  The important part here is that we are going from nothing (the user's mind) to something (the database).

SQL Server Integration Services (SSIS) is a technology that allows a developer to "map out" an in-memory data transformation process.  The important part here is that we are going from the database *back* to the user's mind (typically in the form of reports or other data visualizations).

I think the interesting thing to note here is that these two technologies are *so* similar.  They depend on tasks, create flows, etc., but are not really integrated in any real way.  Is one a sub-set of the other?  How do we think about these two different--yet very similar--technologies.  Do they fit within the same developer toolkit or what?

As a solution architect you have to be aware of these things.

Interesting related reading and reference:
http://www.developer.com/db/article.php/3780676/Building-a-Windows-Workflow-SQL-Server-Integration-Services-Activity.htm

The two faces of business intelligence

I'm most interested in capturing net new data sets, things that have never been captured before.  It's my claim that most of the world is this way: not captured, free.  But there are many examples, of course, of data and systems that we have been able to capture and visualize: banking, weather, etc.

Business intelligence solutions typically concern themselves with the consolidation and mining of *existing* data sets.  Analyzing and viewing existing data in new and interesting ways is really interesting but it is not--by any means--the end of the business intelligence story!!!

I believe that business intelligence is actually two disciplines: 1) data capture (instrumentation) and 2) reporting.  The reporting side of things is the traditional view of BI but I am certain that *no* BI firm can compete or survive without understanding the data capture side of things.  I wonder how many realize this!

Instrumenting and wiring up business processes, tools and "new things" *for the first time* is tricky business.  It requires a special skill set and a creative way of viewing the world: as incomplete.

How much do you care about how the product LOOKS?

This varies—I think significantly—between people. I'm more of a pragmatic / practical person when it comes to computer technology; just make it work…but when it comes to cars, snowboards, stereos, etc…things that are about *me* then I also want them to look cool. But I think software is different. Don't you?

The project database that you want

I wrote yesterday about Project Metadata. There should be more of it. I had a conversation with a friend last night about the need for a tool that supports the "quoting" process for projects. I agree. But there are *so many* other examples of tools that projects need. It's endless, really. From the perspective of MARKETING projects, though, there really are a finite set of things that have to be called out. Many companies have different approaches to this and I would argue they do a completely incomplete job of this and leave customers wondering, waiting, confused.

Let's move past this and get to the age of MATURE project management practices. I would argue that we can't do this without leadership in marketing (it can't be grass-roots / bottom up. Or can it?).

I propose the following schema to be created and supported so we can have an analyzable cube / database of projects for our industries, people, technologies, etc. Having clear insight into these aspects of projects is *the thing* we need in my opinion. LinkedIn just isn't doing it.

• Technology - SharePoint, XML, ASP.NET MVC, Azure, etc.
  
• Language - C#, T-SQL, jQuery, etc.
  
• Business Need - Custom
  
• Tag - Custom
  
• Framework - Six Sigma, ITIL, COSO, etc.
  
• Industry – Automotive, IT, Energy, etc.
  
• Technique/Method/Pattern - MVC, MVVM, etc.
  
• Platform - Windows, Unix, Cloud, etc.
  
• Corporate Offices of Team - Seattle, Boise, India
  
• Person - Who worked on it
  
• Role/Function - Project Manager, Product Owner, Business Analyst, Functional Analyst, Developer, Tester, Writer, Designer, etc.
  
• APQC Business Process - see this page, Develop and Manage Products and Services, Manage Customer Server, Manage IT, etc.
  
• KPI - Sales, Customer Satisfaction, Employee Retention
  
• Client Company / Brand - Nordstrom, Sears, Ford, Shell Oil, etc.
  
• Consulting Organization(s) Involved - Accenture, Deloitte, etc.
  

The projects should also list:

• A Description of the project
  
• List of outcomes / benefits
  
• Rough Size of the project in dollars or people
  
• URL Links for information produced 
  
• Case Study
  

The applications for such a database are many-fold: marketing, recruiting, business intelligence, process improvement, knowledge sharing, community.

Let's get this started today.

Store and share more project metadata

Many professional services companies list their clients and projects on their website for marketing purposes. For example:

• Painless Programming: http://www.painlessprogramming.com/samples . Ben does a good job with classifying projects by Languages, Frameworks, Techniques, Servers, and Operating Systems. This is a very IT/technology-centered view and doesn't really get at business problems, objectives or similar.
  
• Extended Results: http://www.extendedresults.com/portfolio/default.aspx. They classify their projects by category (SharePoint, Scorecard, Reporting, Custom Dev, Data Warehousing) but not by business process / need either.
  
• Cap Gemini: http://www.capgemini.com/. Classified by Industry and Business Need…now we're getting somewhere.
  

What about bridging the gap between the worlds of business and technology. Let's be somewhere in between. I'd classify projects by:

• Geo Locations – Show where you did the work and/or what regions were impacted. Display this on a navigable map.
  
• Links – Tie your marketing site into Delicious.com, SharePoint or similar and list links that the project team used as references. This is useful for the community and for knowledge management.
  
• People - Who worked on the project? Keep resumes…
  
• APQC Processes – See the APQC Process Classification Framework. Use this to describe what type of work you did. Describe which APQC business processes were impacted by the change from the project. Show what you did by highlighting parts of this graphic.
  
  • KPIs – Which Key Performance Indicators did you impact / affect?
    
• Technologies - Which technologies (and versions) were used on the project? Use this to keep track of what technology experience you have specifically.
  
• Resource Types / Roles - Which roles were critical to achieving the outcomes? BAs, PMs, Developers, Testers? Also provide a general description of the roles that you typically use for each project.

Give your customers a new language

One of the biggest parts of being a consultant is getting your assumptions out there, in front of your customers. This could be in the form of a conversation, presentation, or the product itself.

You want your customers driving your development and telling you what they need and want. A big part of this is what I call "exposing the language" to them.

As a developer or product owner, you need tell the market what you are doing (and maybe why). Ie you want to be as *transparent* as you can possibly be.

On one of my current projects I am making a pricing model for the customer and making sure that *he* (and not me) owns the language and improving it. I am just doing my job as a "lowly developer". Know your role. The language is not mine, I am just implementing it.

The more you can engage your audience and push back the assumptions you have so *they* control the outcome, the more free you are to create in an open space.

Clearly know the distinction between what the business process will do and what the software will do

In the work that I do I have to clearly define the difference between what the business process will do (customers, workers, users, etc.) and what the software itself will do. In addition, I have to know what each of the "tiers" (database, server, front end, etc.) of software will do. In all, my job is to clearly define an "activity system" and what all of the actors in that activity system are going to do (and why).

A good tool in this that I learned for Agile Coach Rod Claar is to write your use cases / scenarios / stories in the following format:

<Actor> can <Function> so that <Business Value>.

This is an important pattern for people at all levels of the organization to understand.

The Actor is the person or system or entity that is doing something; your system will have a finite amount of these; the business analyst will have to determine what roles the system tiers will play and what the business people and users will play, it's a big undertaking.

The Function is the thing that the role is going to do. It should be written as an activity.

The Business Value is the *reason / justification* for the actor to do the function. It is the thing that *should* allow people to assign priority and determine what's next. It is the context and is very important.

Aside from these three process characteristics of actor, function, and business value, there are other parameters such as:

• Inputs
  
• Outputs
  
• Time
  
• Success criteria
  
• Failure modes
  

There are many parts and aspects of the system that we have to take into account when designing one.

My current projects

I've been staying really busy lately with quite a few side projects. Right now I have three side projects: my consulting company brand/web site/ strategy, my Visualize Everything idea, and a project I'm doing with some guys called SnoVision.

My consulting company, EfficiTrends' web site is www.efficitrends.com. I worked with a writer and a web designer about two years ago to put the site up. It was built with old (classic ASP) technology and the way the guy built the CSS structure confused me; it's way too complicated and not very reusable. But it served its basic purpose of being something I could point people to. What I've been doing on that site now is building a SQL Server back end and porting the site over to ASP.NET MVC v3.0 and I am using the Razor View Engine. I have been really happy with the progress and like what I've done. I'm using Scott Hanselman's "BIN deploy" method to get my site published to my host, Re-Invent.com. My goal for the site is to make it more dynamic and to list my past and current projects within it. I would like the site to be a comprehensive view of my capabilities as a web developer and I would also like to use it as the hub of my consulting work. There's a lot of work to do here and I'm having fun with it.

My second big project right now is VisualizeEverything.com, my online printing/t-shirt creation web site that is based on popular or community-contributed phrases. I've been working with an intern, Raheleh, on the site and she has been a great help. The one trick with that is I have to get the domain name bound to my home server and I also want to hook up web security.

My third project is helping a team of guys with their Feral Motion project. Feral Motion and their project SnoVision is a technology to automatically record and upload video of action sports athletes as they use "features" (jumps, etc. in a skate park or mountain terrain park). The technology is really cool. I've written some good code that uploads videos to Viddler and stores metadata in a MySQL database.

So I've been quite busy, FYI!

Make and break the model

A key part of being an entrepreneur, software engineer, or scientist is to make and break "models".

Models are belief systems or hypotheses or lenses or ways by which we see / view the world. They're almost always wrong but we have to operate under them.

Making models is what we do when you define a problem, explain a context or situation and define a plan to test it.

Breaking (or proving) models is the goal. We do this when we finally get to test our assumptions and theories. By testing models we learn if we are right or wrong.

 

Six Sigma “Define > Measure” is “Instrument > Collect” in business intelligence (BI) and software

In order for systems to measure anything or "throw off data", they must be instrumented to do so. This is true for cars, business processes, humans, anything.

There can be external measurement devices that observe the object but this is not the best. It is better for things to be instrumented and throw off their own data to the observer so the observation step can happen as part of the analysis.

Next time you build a system think about the needs for instrumentation, then you'll be more prepared to Collect, Analyze, Improve, and Control the system.

The customer is the person with whom you must be Agile

I learned this in pretty major spades on my current project. I was so *focused and busy* on producing the thing that I thought the customer wanted, that I stopped listening to her.

I never came up for air; I never had time to!

I was so sure that what I was producing was the RIGHT thing, that I ended up being WRONG.

I adopted a very "waterfall" mentality on this project because I was under the gun, behind, etc. But from the beginning. This is no way to run a project.

Never start a project without a signed SOW.

The ½ Project, ½ Consulting Rule

Don't plan a project that's only dev work or only consulting and no product.

In project work, there are two primary ways to derive value and succeed:

1. The work product itself and
   
2. The relationship
   

Both matter a great deal, and perhaps equally so…

Always make sure that you balance these two things: save time in the project for consulting and managing the customer's changes, expectations, requests, and questions. In this way, be Agile.

In other words, projects are neither Agile, nor waterfall, they have to be both.

Sculpting the model

Software development of any kind is like creating a clay sculpture:

We start with our understanding of the problem and solution domain (the clay and base) and then we start making stuff. We add, update, and remove until we're happy. Working with 3D forms is much the same as coding.

There are two models at any given time: the ideal mental model in the developer's head and the physical model that has been coded into the software product.

The developer identifies solvable differences between these two models and either A) modifies the code structure so it more closely resembles his ideal mental model or B) changes his mental model (expectations) about how closely the product must conform to his standards.

In other words, software development is subjective, but the judgment of the end product (art) is in the eye of the beholder.

Analyze the process or the data?

I always start with the process because that's what's most apparent and important to me. Things are broken, things are wrong, A isn't talking to B…stuff like that…

All of this context in my opinion matters a great deal and it's what business is all about! We need to change and improve this stuff, I think!! If we understand this part well, then we can create good, high-functioning supply chains, which I think is the goal.

Analyzing and improving data sucks.

Create a common language between the business and the doers – A call for Agile Scrum

Agile-Scrum tries to do this by breaking down work into stories and then further down into tasks. Each task has an estimated time and the aggregate (SUM) of the tasks is the time for the overall story.

So if someone asks you, "Can you do this by tomorrow?" you should figure out what the stories are and then the tasks. If the work is greater than 24 hours then there's no way.

If the business person can get bought into what the tasks are, or if you have a good scrum master that tracks what the tasks are and the estimated time for each and keeps that data up to date, then communications will be good.

If none of these things are true, you're going to be under water.

Sometimes you gotta call for support

I got over my technical head on a work problem today. I need to make this (what I think to be) really hard report for the customer. It uses SQL processes and whatnot that I've never encountered, so I'm basically quitting until I can get a second set of eyes.

I'm not going to keep billing for work on something that's beyond me, so I stopped.

I emailed my boss and told her that I was doing this and listed about four or five others in the company who could help me with and/or do the task.

I think this is a good thing for me to do.

Separate the concerns

It's critical to understand how to do this in our lives. We should never "pool" our concerns, we should *separate* them. We should not panic. We should parse our problems out and make them clear, tangible, and distinct.

Good, sustainable solutions come from this mental process.

You're lucky if you have a knack for this, you're probably cursed if you don't.

When a five minute phone call saves our butt

This is the reason that good consultants and a healthy personal social network are essential.

Without our advisors and experts, we're nowhere. We can read and dig in and shoot in the dark, but sometimes we need consultants and experts to *help us solve our problems*; we have to escalate.

The reason I emphasized the "help us solve our problems" text above is that this is absolutely critical. We have to know that we have problems. We have to know that we have to solve them and we need to know that others can help us do this and that when the answer is given that we are able to apply the answer ourselves!

You don’t have to code it but you do have to pseudo-code it

You're nowhere unless you understand how the software either works or needs to work. This is the gap, generally speaking.

If you don't understand how the software works now, you won't be able to bridge the gap between the software devs and the business.

If you don't know how the business works now, you don't know what you're doing or why. You're about to get fired; you're dead weight.

Somewhere between these two worlds are people with the skills to bridge that gap; to bring needs into reality and to bring technical opportunities and problems into the light of day.

These people are the real leaders in our organizations; not people who take one side or the other but get both intimately.

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?

The next step vs. the *real* next step

It seems like there's almost always a gap between what we might think we want to have happen and what actually happens. Ie plans are infrequently realized.

The next step that is usually realized in a work/team environment is either:

1. That which two or more people agree to take or
   
2. That which one person wants to do because he/she wants to do it
   

The former is more collaborative and probably less frequent. It promotes better teams.

The latter is probably quite common because the actors in the company are the doers and there's usually no one standing in the way of the doers. People typically favor action. Another consequence is that those with the ideas and suggestions rarely get to implement their ideas because they're not the doers.

Sometimes the Band-Aid is too big to use

Sometimes the only solution you have is too monolithic to consider. Bail on it and keep thinking.

The Hard Part: Making the Product the First Time

It could be argued that creating a process or prototype / product / model of something for the first time is not the same as producing or selling that product in mass scale. But they're kinda related, right?, because it's all about changing and innovating… I'll try to distinguish between the creation and the birthing.

Doing something for the first time is creating the process or business. It is akin to giving birth.

Selling the product after it has been created and first shown is akin to raising the child. It is a constant selling process.

Let them set the urgency for their problems

Sometimes others' problems really are not your own; but they have to be. When I encounter this type of situation, I like to let the other person drive; make them set the sense of urgency and schedule things. Let the sense of urgency happen on their side. When they approach you with their thing, be nice, have good customer service, and move forward.

Forget about the Non-Current Impediment Now

Don't waste your time thinking about something you could do later. If you're not fighting a fire or doing something urgent and important now, then you're wasting your time. Find the person that's fighting fires and take their direction on how they need help. If they don't need help, then something's wrong; you're not supplying them enough resources.

Be Selling or Be Solving

You've basically got two choices in work and getting things done from a communications perspective: solve it or sell it.

Sometimes the sellers have to be solvers, and sometimes the solvers have to be sellers.

Know your role and what you have to do next. Be flexible.

Learn on the Task Incrementally or About the Framework Overall

There are two primary learning methods in my experience:

1. Learn on the task at hand (either by figuring it yourself or asking someone how to solve/do it)
   
2. Learn the overall framework or system (requires good connections, time, patience, and money)
   

Learning via method #2 is a luxury that we sometimes get. We want more of it but can't always find it because we don't know enough people who are as smart as we are or know as little as we do. I'm currently in a project that requires quite a bit of #1 work and I don't really have too much help on it.

We need to get better at learning in both of these ways.

Many Professional Services Compensation Methods

From what I can tell there are just a few sensible ways to pay a professional services worker:

1. By the hour on billable client work
   
2. By the hour on non-billable work (process improvement)
   
3. As a % of billed project work (sales)
   
4. Fixed fee for bringing on new consultants
   
5. Fixed Salary
   

And metrics at play that would allow you to build a model are:

• Billable hours
  
• Hourly bill rate
  
• Total billed on project
  
• Number projects
  
• Wage Costs
  
• Number billing consultants
  
• Margin on work
  

I want to be able to get paid for all of these methods but the company has to first determine how all of these options work such that the company can continue to grow rapidly and sustain its growth. No small task but I hope to continue to think about and develop a formal, flexible software model for this.

Business Intelligence: The Stuff You Don’t See, Know, or Understand

Business intelligence are the things that happen "behind the scenes" to achieve a business outcome. Business intelligence are the outsourced or "hidden" capabilities that the IT application or service provides for you without you knowing.

More later.

Distinguishing *Kicking* Major Booty from *Kissing* Major Booty

In order to get ahead we sometimes have to "kiss ass". It's not fun but we probably all do it sometimes. It's even a skill I would argue.

But it's not the same as "kicking major ass" and it's really not the goal. Let me explain. We can get ahead in one of two ways: A) climbing the ladder and B) doing good work. Climbing the ladder *may* come as a result of doing good work but can also come from kissing ass and "who you know".

Try to climb by kicking ass (doing good word) rather than kissing ass (building relationships) but recognize that don't matter and you probably can't do one without the other; you attract more bees with honey.

We want to manage our organizations, don’t we?

I blogged earlier (http://kickmajorbooty.blogspot.com/2010/06/why-do-organizations-have-top-theory-of.html) about the Theory of Wringable Necks. We want things to wring, manage, grind. Why? We require visibility and manageability. We don't want unmanageable things, or do we? Do we want chaos or order, variability or knowledge?  Probably both.

Do the Math Because Life is Math

Why is this true? Life is a collection of tests. Tests must be clear, visible, and verifiable to be quality and so must life to be brilliant, resistant, and attainable. Test life with clear goals, visibly today.

Your Organization *is* the Test Suite

How and why is this? Somehow it's true. If you see your organization or life as a collection of tests, you're set to succeed. But you need to make this a visual, visible, and measurable (external) system/process. How? Read on.

You have to know and define the *process* and *way* by which you will achieve your goals; you have to develop a tool and measurement system that throws off data that you can analyze. How? What's the data, what's the system, what's theprocess? What's the context? Read on.

You want to test and achieve your most important goals. Project management can help you get that. Goal statement and testing / verification of goals to achievement is necessary. You need data to *control and manage* your business. This gap *is* the system; the third leg of the define, do, achieve goal. It's how you adjust and get feedback.

A project is collection of tests. An organization is a collection of tests.

Tests arise in a couple of forms but the bottom line is that you have to be able to verify them *in* the computer, not in your head, against the model.

• Acceptance testing: does the product perform against the expected actions? (doing this requires you to document the expected actions or activity system as a model but this is hard to verify because it is subject. Subjective = bad for organizations)
  
• Unit testing: does the software created allow itself to be tested against a collection of tests, the policies and processes of the organization? Are the tests managed and maintained? If yes, this is good. This is visual, this is visible. Verification is good.
  

The activity of running a life or business *is* managing a collection of objectives and tests. This is often not done visually or systematically and is most commonly done randomly and individually. Bad!

As leaders, let's reduce the variability in our lives and organizations by managing things concretely and visibly; data-driven. Start unit testing your development projects today. Build your test suite as you build your business.

I Became a Very Strong Proponent of Adopting Organization-Wide Test-Driven-Development (TDD) Today

For years I've known about software testing but I never had to apply it. This probably means that I wrote crappy software; but the bottom line is that people "accepted" it, one way or another. I used to just "get by". That all changed today.

I used to be a DEVELOPER, plain and simple. I'd write a web site and show it to the customer or users and it they said it was done, it was done. Then I became slightly more advanced in my practice and learned about UML "use cases" or "scenarios"; user stories. I learned how to write a stories and workflows and make software that aligned with those high level structures. But there is an even lower level that I had to go to that I was missing: unit tests. These matter!

My brand new tool/to y in my tool-set/toy-box are unit tests. I love these. These are important. They are critical. They are potentially even THE GLUE that could unify technical and non-technical types. They represent A LANGUAGE that can be understood by technical and non-technical types together that could be a unifying force in the process of designing custom software and business rules.

Acceptance tests, use cases, scenarios, and this kind of stuff are too "high level". In a way they are very "ethereal" (understood by few) and unverifiable. One person might think the test passes, and the other doesn't. In that sense they are very QUALITATIVE and ambiguous. Bad juju in business and softare!! Bad!

On the other hand, writing unit tests and ensuring that the code or business rules you write (policies) adhere with the spirit of the law is a beautiful thing. They are very low-level, understandable, and I would argue are NON-TECHNICAL. Yay, a non-technical thing for describing the business rules and logic that must be written. Awesome! Win win!

Overall, I think our organizations need three, types of people: Those who make rules, those who break rules, and those who watch the system and determine what to change. Each of us may need to be all three types of people sometimes; wear many hats. But having these clear distinctions between responsibilities is, I think, game-changing.

Clearly Separate Your Inputs, Process, and Outputs - Know the Jobs of Everything!

When we write spaghetti code we mix all of these components up. We're not clear on the jobs of things so we make everything do many things. And it gets confusing!

On a data warehouse I'm building I have to be very clear on what are my inputs (the stuff flowing in), what is my process (the things I'm changing and I have to use temp tables during that process) and what I am outputting. Each one of these stages and events needs to be very clearly separated; ie I can't ruin my inputs while creating my outputs.

I have to preserve everything but also be able to create and destroy everything as well. That's a lot of power to harness.

Be Cooperatively Tenacious

Merriam-Webster's defines the word tenacious as, "persistent in maintaining, adhering to, or seeking something valued or desired". The only thing I would add is do this TOGETHER with someone and be tenacious about your ideas WITH others.

Never Burden the Customer with the Backlog – Keep them Focused on the Product Itself and Let them Go About their Business

If you are good at product development, then YOU and not the customer will keep the product backlog. Never burden the customer with the list of open items or anything like that. The goal is work and progress and not the list.

Today I had a meeting with the customer and we agreed on the items that needed to appear in the next iteration. We made the list together and I shared it with him over email before I began. I'm now code complete on all of the changes. But I don't want to burden him with this detail. All he wants is quality, working software, not any administrative work.

So I'm going to demo the product to him tomorrow and tell him that all of the stuff we'd talked about last time was integrated and that we are now on a whole new review cycle. This keeps things fresh and focused.

Don't carry too much process baggage with you. The goal is the product, not the process, supporting artifacts, or other metadata.

Iterations to Demonstrate Mastery of Understanding

Having a meeting with someone where you show them your work and/or art is great. Be thankful for an audience and a customer!! In these reviews there will ALMOST ALWAYS be comments, needs, and next steps (at least you should hope there are or you're likely out of a job!). So be very clear on what these are and commit then with them to the next iteration. Work with them through the process without bothering them too much. And then, when you're ready for a big demo with them (and another iteration), go for it!

There’s Always Another Piece of Art to Modify

Just because you demo your product or project to someone doesn't mean that you're done with it but sometimes you are indeed; that's the definition of "shipping".

As creatives, developers, makers, and artists at some point we have to let go of our art pieces and realize that our demo is indeed our FINAL demo; our MASTERPIECE…and we stop working on it. We ship it. We let it go.

There will always be more comments and more feedback on that thing but at some point we look the other way and move onto the next thing.

Think about De Vinci and the Mona Lisa, for example. At some point he surely said, "I'm done" and walked away. The feedback kept coming on it but he didn't look back and modify THAT piece of art; he modified others.

Why Do Organizations Have a “Top”? (The Theory of Wringable Necks)

Organizations have a top for two reasons: accounting and accountability purposes. In our organizations we need "single wringable necks" and modular, replaceable parts so we can distribute risk and seek remedy as necessary. We need to know the parties we can rely on and those from whom we can seek remedy. In a way we are distributing our risks and interests to many players; outsourcing.

When it comes to organizing things, we like to "pool" our resources amongst many players; but we like each of them to have a very clear role and responsibility (jobs).

Take the case of cloud computing: "Put it in the cloud." (A single, centralized place). The redundancy in the cloud is the thing that *would* make us trust it. We as people rarely trust single entities alone, in isolation. We frequently create backups and distribute our risk; we often "trust but verify".

We need the things in our lives to do specific jobs for us so we can rely upon them for living our purposes. The only way to manage in this outsourced context in my opinion is to make our things' responsibilities very clear; oftentimes contractual. When the things aren't living up to their responsibilities and agreements, then we need to change them, the contracts, or start wringing wringable necks.

“What It Means” and the Definition of Done Are Constantly Changing

Given our current experiences, situation, and knowledge, we are able to determiune "What It All Means" and decide what we are going to do next. When we do some, most, or all of those next things we are able to re-assess where we are at and where we need to go (again). In other words determining "What It Means" is context-sensitive, constantly changing, and fluid. So, BE AGILE!!!!

Never Ever Ever Ever Underestimate

In our work lives we frequently have to make and keep time-based commitments and estimates and work to schedules. This sucks but it's sometimes and for some often a reality. How do we cope and deal with high-pressure situations like this? By NEVER UNDERESTIMATING!

The old axiom is "under promise and over deliver" and that really is the goal. It helps with work life balance and a variety of other things. Doing this well has so many benefits it's amazing. I hope you can do this well and get good at estimating "just right" to give yourself some breathing room but not be overly padding your estimates such that's it's ridiculous and you're seen as lazy.

Appreciative to have finally landed/settled with my career (at least for now)

I was really good at building web-based systems when I graduated from college in 2000…at least for the time in my head. I was quite confident about my skills to say the least (cocky is probably nowhere close to an understatement). But my problem at the time was that I hadn't yet been able to realize my vision and in a lot of ways I was pretty insecure. I was very ambitious and wanted to build really big systems—and did build some—but I wanted more skills so I went back to school so I could achieve more.

When I went back to grad school at the University of Washington Foster School of Business I learned a few things:

1. People at work and in my life expected that I was getting an MBA, not a technical degree (I was getting my MS in Information Systems at the time)
   
2. I learned A LOT about how to build systems that matter to people; I learned that business and business process is the real need and driver behind IT systems and that IT systems should play second fiddle to these more important factors. In this way I become much less of an idealistic pro-technology at all costs nerd.
   

Because of #2 above, I decided that I really didn't care too much about IT anymore and what I really wanted to do was get in management and AWAY from IT. I tried.

Fast forward two years from then to last fall when I was unemployed and needed work. I got a job as a software developer again but I was really rusty with my skills by this time even though I was probably WAY sharper analytically and from a thinking perspective than I ever had been. It took me many months (9 now?!) to feel confident with my software development skills again. I'd now say that I'm a pretty good software developer again. And I'm not worried about being one at the moment. It doesn't bother me that I'm writing code again because I know that I am also a talented analyst and project manager and I have my masters degrees and PMP certificate under my belt; my confidence is currently pretty high.

In total I guess I'm saying that I'm very thankful and appreciative right now for the roads I've been down and the place that I'm at now with my career. I'm 33 years old, 10 years out of undergrad, 5 years out of grad school, and I feel pretty good. I'm a consultant for a pretty cool company and make a pretty good wage with benefits. I like what I do. I'm technical and non-technical, businessy and nerdy at the same time. I think that I can go this way or that in my career (make choices that don't have ridiculous costs and consequences) and I really like that agility. I'm happy I finally landed here, it was a very long road.

Rhythm and Cadence (Predictability) in a Project or Program is Hard to Come By

It's very desirable to get into a pattern where you plan, then work, then deliver, then review, then do it all over again. The goal is to limit interruptions and make things predictable. Let the people do their jobs and don't let the jobs conflict or adversely impact one another. Harmony is a good word here. Of course this would be nice but it's not always possible. These phases, people and interests often overlap and sometimes get out of sync.

My current work project has a fairly decent cadence but it is not perfect. Overall we're doing a pretty good job. We usually plan on Fridays and deliver on Fridays as well. We commit for the next week late Friday. This gives us a day to assess where we're at and what we're going to do next week; but of course these plans can get interrupted by changes in the following week. In our project, the policy is "what is committed is the sprint" and everything else is the backlog. If we finish the sprint early, then we can work off of the backlog items of course. We've been lucky to not have too many fires. Sometimes the sprint itself generates more backlog items.

Product Manager, Business Analyst, and Solution Architect Roles: They’re All the Same

In my opinion a Business Analyst is someone who "gets it". I would say the same for a Solution Architect and Product Manager. They understand technology and programming well enough to determine the solution with the customer. They also know and understand business well enough to think through what's practical, pragmatic, attractive, and scalable from a business perspective. They are smart enough to work with developers and engineers to explain the solution requirements and do some translation.

Contrast the business analyst type person with a database person (what are their skills other than they can write SQL and work with databases?), and with a user interface specialist (who knows how to make a pretty user interface but who cares?).

Where's the process person in all of this? Who's the person that cares about the system and customer more than they care about a particular technology or capability?

In business in the end it's all about making kick ass products and services that people love; it's about engaging and possibly entertaining people. Loving one side of things (business, technology, user interface, design, etc.) too much is short-sighted. Focus on the customer, the market, and how to make as many people as happy as possible; and forget about yourself in the process.

Being Serious about Attempting to Deliver Quality is the Same Thing as Confidence

From where does this type of confidence come? How and from where do people get it? Experience? Is there a source where I can find more of this energy?

You can't have confidence all the time. Sometimes you can "act as if" and get by but that not everything; unless you're in sales. If you are ever on the hook to do the work or job yourself (engineer a solution or produce a product), you have this sense of urgency and serious about yourself and that is not confidence. In fact I think that having that sense of urgency and seriousness about yourself actually DETRACTS FROM your confidence in some way. Confidence can be thought of as arrogance.

Is it so bad to doubt or be skeptical? Maybe in sales.

I guess I'd rather be scientific and fact-based rather than overly excited about "opportunities" myself.

Being confident all the time isn't possible but we want it for ourselves. When it comes to work, in the end SOMEONE has to be the one who takes the lead and ACTUALLY delivers the product with the skills, resources, and connections they have to the customer. This product has to be delivered to the level of quality that the customer actually requires, to a "confident" place. Delivering quality, to me, is confidence. But to get here requires much, much more.

I Hate You, Copy-Paste Coding

I'm doing it right now. It's the worst. You have to do it sometimes but when you do it, you create redundancy and inefficiency in your program.

Alternatively—and sometimes there is no alternative—centralize your logic and create reusable components. Time-constraints and complexity sometimes (frequently?) prevent this from happening.

The innovation can and will come later. Doing things poorly is often a good lesson for how you'd do it better next time.

Avoid Creating Roles - Everyone Does Everything

This is the type of culture that I want in my business. BluWater Consulting's scrum practice did this very well. Everyone on the team had a variety of skills from UI to the database and everyone TOGETHER was responsible for delivering the product successfully. The bottlenecks in the team were what they were and there was no preconceived notion that the company could perfectly staff a project with just the right resources. So they instead hired good balanced players and made sure that OVERALL they had the competence available to build the solution. They started into their projects aggressively and the team sorted itself out and figured out how to organize in order to deliver as effectively as possible; roles were project specific and always will be because there are different casts of characters on every project.

My current company is considering making teams of UI specialists people and teams of Database specialists generally and for each project. I'm not so much into the idea. I don't think we should be creating practice areas; we already know who the specialists are. Let's not take the focus off of shipping the best product with the resources we have and think about "organization". We need to organize around THE CUSTOMER, not ourselves and our competencies!

Yes, some people are talented designers and very artistic and others are highly mathematical and systems thinking but let's not pre-focus our teams on concepts other than the customer and getting things done.

Keeping the Baseball Book

When I was on the varsity baseball team I spent a lot of time as the "book keeper" because I was not good enough to be playing. I got REALLY GOOD at keeping book in fact. That's probably how bad I was at baseball.

I was doing programming working on my project for the customer today and thinking about some of the conventions and practices I am following on it—from coding standards to the way I format the font and release notes when I share the product with the client—and was reminded of how I used to keep the book. I used to be VERY anal about how I would keep the book and I would not let some of my teammates keep the book. Even they adopted my conventions and followed them. I heard years later that my format of book keeping on the baseball is still in tact; it's called "Veal book" and the team regulates it.

The goal in any business is to be consistent and let others see your quality ways through the conventions in your products. Be good and careful with your products. Put on fit-and-finish. It shows through.

Refuse Help That Prevents Greater Things from Happening (And Other Lessons I Learned from My Current Project)

I recently had the opportunity at work to accept help from a new resource. Accepting his help would have taken a lot off my plate and freed me to do other things; it would have taken a lot of stress from me. I came to find out after the resource was provided to me that he was also expected by a paying customer at the same time in her group full time. Because my project has a limited life and I believe I have no more right to the resource than a paying customer, I decided to let the resource "go" and I am now back working primarily by myself really long hours again; it's not fun. But I don't regret the decision at all; it's better for everyone (except for maybe me, now)…I'll elaborate.

Other than this lesson on the project I've learned a lot of other things, too. Below is a list of my top lessons from this project.

Some quick background first: I'm new to the company, new to the client group, and new to the type of project/product being produced: a reporting system re-engineering existing reports and merging several systems into one. I've been with the company for just under three months now and was hired on this project as a business analyst / delivery project manager.

Top 15 Lessons from my current project:

1. Ask hard and tough (AKA good) questions in job interviews about what the project you'll be working on is, who the team is, and what other projects the team is working on; don't get involved in projects that are under-staffed. Ask about the company's recruiting plan if you identify that there are not sufficient resources to finish the project to the customer's timeline.
   
2. If the project is getting behind, don't be a fall-guy / hero and jump in and do the work yourself; raise it up the foodchain and stick to your role as manager; not doer. This is one of the primary places where I fell down on this project.
   
3. Ask what priority your project is in the overall scheme of things within the company.
   
4. Ask if the project is "just a project" or if it is more likely a larger program / sales opportunity.
   
5. Ask the company about how they think about and implement work-life balance
   
6. If a long-standing technical resource on the project tells you that a request from the customer is non-standard and out of the norm, raise that issue up the flag-pole as fast as you far as you can and as soon as you can.
   
7. Be good about openly communicating risks; don't be paranoid.
   
8. Don't start in groups where you are expected to be a subject matter expert from Day 1 if you are not a subject matter expert.
   
9. Be willing to make timelines that project a ways out; they can always change. Think of things "thematically" and long-term.
   
10. Never let non-technical managers drive technical meetings or participate in coding sessions. Follow "Pig and Chicken" rules. Chickens like sales people are only partially committed while you as a pig are on the line to deliver it all.
    
11. Create an "electric fence" between the Pigs and Chickens (engineering/delivery side and sales side of the business). Don't let these two worlds cross-pollinate at the lowest levels of the organization but ensure that there is a VERY STRONG interface between these sides at the higher levels of the organization. Without this interface/partnership/discourse you really don't have a business at all; rather confusion, finger-pointing, unfulfilled expections, ridiculously long "death marches", and customers left in the dark.
    
12. Kill "old school" project managers who try to manage everything by dates and matrices. Not everything will fit in the matrix so forget about it. Keep a product and task backlog and share it with everyone. Buy and use good IT tools like AxoSoft On-Time for managing your projects. Make sure everyone has an account.
    
13. Establish a recurring delivery cadence and rules about work-life balance. Don't expect the project team to kill itself to make the customer happy.
    
14. Stop the sales side of your business NOW if your supply side (hiring or delivery processes) cannot keep up with the demand.
    
15. Always think mathematically and in a clear, data-driven way about demand (who needs what by when) and supply (can we get it to them)?
    

Overall I learned in this project that business is about risk and taking risks. Some people can tolerate more risk than others. I took this job not thinking of it as a risk but an opportunity. It has definitely been an opportunity for me to learn a lot about this organization and about getting things done. I also learned about a new subject area: report system automation and system integration.

I hope that my company matures its operations rapidly, that my current project wraps successfully and becomes a program/lasting account, and that my next project is fun, insightful, and does not require so many hours. (I worked a 14 hour day today BTW, and two weeks ago I worked 40 hours in three days. That is NOT THE GOAL!)

Why Wait for Someone Else To Do It When You Can Do It Yourself?

Building Big Databases

This is probably one of my bigger passions in life. I'm not sure why I like it so much. It must be a "control" thing for me where I want to have control over a domain or set of people; a system. I want to create new domains that I can advise.

Always Fix the Weakest Relationship in the Team

Dealing with talent is tricky. In my company we have a guy that's good at organizing people and things and a guy that's great at selling things and dealing with perception. These two—if they knew each other well and how they can benefit each other—would be the perfect duo to kicking major booty. They don't currently realize how critical each other is to their mutual success—and mine. I'm trying to put bugs in each of their ears so they can start working together. Teams require strong individuals and strong relationships. Always fix the weakest relationship in the team.

The Middle-Ground Between Developer and User

What the developer cannot see (but tries to understand) is what the end user sees. Through feats of magic and mayhem, the developer tries his very hardest to be in the shoes of the user and understand all of the needs that the user has. If the developer did not understand (or think he understands) what the user's needs are, then a solution could not be developed and delivered. Yeah, a developer could "totally wing it" and shoot in the dark for a miracle but that's not the goal.

The developer has to put herself in the shoes of the user but can never BE the user because she IS the developer. It's hard to be two things at once and this creates a blindspot.

Speak Your Needs

Not too many people are good at this. I'm not. As people we have to get a lot better about this. What do I need? What do you need? How can I help you? Many of us are probably either unwilling or unable to tell people what we really need. Some of us—myself included—may believe that they don't NEED anything…that they're "good". But none of us are good. None of us are complete. None of us are without the need to connect with and relate to other people and key concepts.

I'm setting a goal for myself to tell people what I need more often.

Try to Be Aware of the Consequences of Your Requests

For every action there is an equal and opposite reaction.

Don't just ask for stuff because you want it. If you're doing that, then it means you don't really understand what you need. Maybe you don't need anything at all. Maybe you are not deserving of using the thing that is given to you. Maybe if the gun you want is put in your hand you will shoot people with it. Be careful on what you wish for.

Trust is a big thing and something that is very hard to manage.

Sometimes It’s Good to Assign Blame

When you get to the end of a project, it's good to level with people and tell them how you feel. Not a full-on berating of the individual but an assignment of responsibility for consequences rendered. Do you agree?

Consulting as Learning to a Job Better than Anyone Else Can Do It

In the company that I work for we have a very flexible way of working. It is very "agile". There are no managers per se, although the pecking order is pretty clear at the highest levels. When it comes to the "consultants" (workers), however, things are very open and undefined. This is both good and bad. For example, in me looking to figure out what I am going to do next, I am likely going to find someone within the company who "needs help" doing what they're doing. This person could also be a client who "needs help" with what they're doing.

One of the following things could happen:

• I help them and free them up so much that they can move onto something else (I become the owner of the role or function)
  
• I work with them and figure out the my skills are way different or are complementary to theirs and we grow the team together
  
• I go try to do what they're doing and it is either not my interest or not my skillset and I bail
  

I'm hoping in my next gig that I find #2 but I'd be just as happy if #1 occurred.

Who is the risk/problem on your project?

Pray it's not you but beware because it could be. Figure out what you have to do/adjust in order to comply and take the pressure/attention off yourself. Do everything that's in your power to get out from behind the impediment, project, or task you are facing. If the project / problem / focus does happen to be someone other than you, then make sure they know it but be kind in how you tell them about it. Help them through the process and change curve. Don't embarrass them. Give them a moment to shine. Make the focus constantly change. Everyone should be the impediment / bottleneck at least once in your project. If they're not, then they're not critical path or necessary.

Be the guy that *is* the bottleneck

At work you're in a much better position if you are the guy that *is* the bottleneck than if you're the guy that *creates* the bottlenecks. Don't be the latter. You'd hate to be the guy that makes things slow or inefficient in the system through his actions in/on the system, tasks, and people. We all have limited bandwidth but don't be the guy that creates limited bandwidth in others. If you are this guy, question your policies, actions, and practices and determine what you can do to empower others and the system to be their/its best. Facilitate the production of the system; don't insist that you create it yourself. Be responsible for creating both the product and the process! The system (in my opinion) is intended to be created by/for the people, not something to be imposed upon or forced upon them.

When to Delegate, When to Collaborate

Most business processes require COLLABORATION (shared activities) and DELEGATION (solo activities). Sometimes you really just want to GIVE work to others and not worry about it and other times you want to SHARE work with others. There are times for each modality. Some people use one too much.

On my new job I am way more in the COLLABORATE mode since I am still learning and want to build relationships with my peers.

Here's how I like to work:

1. COLLABORATE
   
   1. Find the work and understand from the customer what it is, what its success is
      
   2. Share the work and needs with your technical collaborators and figure out what needs to happen for this thing to be successful
      
   3. Determine everyone's roles in the production of this product? What will be shared, what will be solo?
      
2. DELEGATE
   
   1. Do the work and finish the work
      
3. COLLABORATE
   
   1. Determined what you learned and repeat
      

Lots of collaboration. The delegation only gets done after everything is defined and clear, and then you send people out on their mission; very little ambiguity is left. I like it this way and I think this builds better teams and products.

What Is the Impediment Blocking?

"Impediments" prevent us, our projects, our processes, and our products from being efficient, effective, and complete. But not always at the same time or in that order.

Below is a brainstorm of what impediments cause by type. I'd like to know your thoughts.

Personal Impediments

• Blocking "me"…what does that mean? How? Why?
  

Project/Task Impediments

• Blocking start
  
• Blocking completion
  
• Blocking continuation / next step
  

Process Impediments

• Blocking flow
  
• Blocking completeness
  
• Blocking quality
  

Product Impediments

• Blocking completeness
  
• Blocking quality
  

Do You Want Daily/Weekly Rhythm and Cadence or Real-Time-Collaboration?

When you're working hard toward getting to the finish line, many questions come up. Sometimes it's best to get information / input when you need it and other times it is best to DEFER getting the information. For example, if you customer joins you on a daily call, you can save all questions you have for that daily call and work on everything else. If on the other hand, you need/want the input from the customer NOW, you have to make the call and put up this "blocking issue".

Randomization of resources works both from customer-to-dev and dev-to-customer. Neither one of these parties should want to be constantly pinged by the other with needs and questions; that is unless their mutual goal is THE PRODUCT and the customer is HAPPY to be bothered with questions. If, on the other hand the project is seen as a burden and something that they are both going through together (A PROCESS), then they should touch base on a daily basis.

Thoughts?

Quick List of Ideal Software Development Project Commitment Policies

1. I work as much as I want to work; I can kill myself working a lot if I like. I can be a "rock star" and do all of the work for everyone if I like.
   
2. People get paid for the amount of work / points they deliver to (it's a competition)
   
3. We as a team are responsible for delivering to our commitments
   
4. I am responsible for predicting how much work I can do for a sprint
   
5. I am responsible for delivering the amount of points / work I committed to for the sprint
   
6. If I do not contribute my "weight" in the sprint, then other teammates have to pick up my slack; we are in this together

Perceiving a Constraint

We don't always realize that there is a constraint somewhere. We don't always realize when people are hurting, are overloaded, or overworked. I've been killing myself on a project (regularly working 12+ hour days) for the last month. It's not a reasonable or sustainable pace that I'm keeping. I am unhappy and the customer may be finally starting to become OKAY. They had really high expectations and we had a fixed resource constraint so I jumped in and did a lot of work. But my over-working is about to come to an end.

Hopefully soon, the customer will FINALLY REALIZE that there is a constraint in place and I have been that constraint. I can only do so much and that has to be understood. I can no longer continue the grueling pace that I've been under.

Be careful what you wish and ask for. Be careful of what you sign up for. Try your very best to set REASONABLE EXPECTATIONS with people and get out of the business (if you have to) of doing things above-and-beyond or setting stretch goals. You can only stretch for so long; at some point you will break.

Do Something New without Breaking Everything You’ve Done Before

Systems are weird in this way. Adding something to your database / model COULD BREAK EVERYTHING. Getting good at adding things to your model without breaking everything you did previously is a very important skill to have!! Taking good notes about what you did do is pretty critical here. And being able to "undo" is also very critical…

The Project is not the Project Management, It is the Work

Don't confuse making fancy charts and graphs and figures and all that with the project itself. The project itself is that which produces the product. Nothing else.

Programming Should Be a Spectator Sport

I'm working to a deadline right now (yes, I have time to write a quick blog post when a good idea comes my way!) and am keeping track of my method and what I'm doing / producing and my assumptions and bugs generated as I go. I'm using MindJet MindManager, one of my favorite pieces of software (if not my favorite indeed). As I go, I am iterating and going down the road and making notes and fixing things and logging what I did. I'm tracking my progress in a document other than the code. I think if someone were to write a web service / site that sat on top of my MindManager file then it could be interesting for my project managers, team, or customer to look in and see what I'm doing. As I create new objects in the file, it would be a running log of what's going on. They could write things into what I'm doing and say hello, correct me, direct me and answer questions.

Bottom line, I'm going down the road HARD to make a deadline and deliverable and making A LOT of assumptions plowing the path. I'm prepared to review them LATER, but not now because I am busy and it would take a long time to "catch someone up". But if they were watching or could watch my "timeline", then they could see what I had been doing and we could share that information.

For now I will work in MindManager and plan to share my assumptions and questions later; after delivery.

This process could be improved.

Forget about Project Managers

Leadership, partnership, project, and business success happen at the Program level, not the Project level. Very few peoples' fortunes or successes are made on single projects but rather through well planned strategy and well considered tactical execution. If you want to "win it big" on a big project, go out and buy yourself a lottery ticket instead; save yourself the headache.

If on the other hand you are serious about turning around your business and are not sure how to do it, think twice before you go out and hire someone to "do a project for you". Instead, hire a program manager or "true consultant" and invest for THE LONG HAUL in someone who can understand your business and professional needs OVERALL and help you transform your business into what you want it to be.

Projects are temporary endeavors and necessarily have an end. Programs do not necessarily have an end; and their purpose IS sustainability, which is VERY DIFFERENT from the purpose of projects. The purpose of projects is to "have an impact" or "kick major booty" but these things are not sustainable or reasonable by themselves. There has to be a plan!

Management can't be careless or wild in today's complex, competitive environments. No project can deliver successfully without having something like a Program Office or support organization who can "catch it" and its results and maintain the things that it did or didn't deliver. Nothing in our universe is standalone, atomic, or unaffected by outside forces, projects included. They are not atomic and cannot be treated so; they must be treated as a program or portfolio.

People who shoot for big results through one-off projects are the true entrepreneurs and risk-takers of our era, and probably stupidly so.

Maybe I Studied Management So I can be a Programmer

I have a Masters degree in Business Administration (MBA) degree from the Univsersity of Washington Foster School of Business; one of the Top 20 business schools in the nation. I earned that degree about four years ago now.

I read about management, study management, and leadership frequently. I care far more about people and processes than I do about particular technologies but I love technology. I have to be a technology builder sometimes; the engineer; the guy that actually makes the thing. And I am good at making the thing…sometimes…

When I went back to school, I wanted to improve my technical skills and learn how to make "bigger systems" and increase my chances of getting promoted and hired; more upward career mobility / momentum. When I went back to school I decided not to do MBA school and instead decided to do the Master of Science in Information Systems program.

But when I finished my MS degree we were lured into doing "just a bit more school" and get our MBA also. I and quite a few of my classmates—probably half—chose to take this route. So we have MBA degrees also. What good has this done? Gotten me a lot of jobs.

I am technical and not technical at the same time. I can dumb it down. I am business and not business at the same time: a walking contradiction.

Let’s Bring Interests Together

How many levels of translation / communication / management are required to support / separate / distance "competing" world views / opinions / people? What if they weren't competing at all but had the same goals and interests in mind but just didn't realize it?!

Examples of this pattern exist in technology (say between "marketing types" and "mathematical types"), in politics (say between Liberals and Conservatives) and in religion (say between Christians and Muslims).

The goal in my opinion is to have good and healthy dialog, debate, and constructive action for these two groups. I don't think war is constructive; maybe some would disagree.

How well each of these sides is organized is interesting but how about THEIR INTERFACES? How well are the interfaces organized?! Probably very poorly.

Let's ORGANIZE THE INTERFACES between competing factions toward productive shared means and goals; let's program manage this stupid dysfunction!

You’d Rather Plan, Do, Check, Act than Do, Do, Do, Act

Plan your work and work your plan. Quality is job one. Sometimes these things don't come to fruition. Sometimes you are left alone to do everything, no time to plan or to check your work. When the work is checked, it results in another "Do" cycle and you are randomized while in the process of doing another key thing. You can get out of this spiral but only if you have help and process.

On the process side, if you REFUSE to work until there is a plan that is one way. If you INSIST to not start the next thing until the previous one is done, you will help yourself. But these things aren't always possible. Insist that people get into a reasonable cycle and care about the project/process overall. It has to be fair or it will never succeed.

On the help side, you can get help. You need at least one other person to PLAN WITH and you need people to give the customers time while they CHECK. And you need to be given the chance to plan and act on what was checked.

You Can’t Manage It if You Can’t Do It

Identify the Bottleneck and It’s Source

Where is it? Is it in your project? Your process? Your tool? Your team? You? You have to determine it. Sometimes it's tough, though, hard to identify. But if you have a high enough sense of urgency and focus then you will get very good at determining WHERE the current bottleneck is in your process or system and what to do about solving it. Be the master of your domain and seek to continually grown your domain.

Create Influence from Wherever You Sit

Whether you're the big boss or a little pee-on minion or somewhere in between, create influence in everything you do no matter what you do. Be upbeat, be strong, be positive, be persistent, get results, and fight for what's right. Get things done and charm people.

Care about the Content of the Matrix more than you do its Form

Sure, you can make a table, a matrix…good for you. But is the data that you have just shoved into it valid, interesting? Spend your time focusing a lot more on DATA QUALITY than any rigid ideas you have about "this must fit". Maybe it simply doesn't fit and you have to break your matrix in order to accommodate a new item. Be flexible.

It Will Never All Fit into the Matrix

There are people in this world, myself included, who need to think in terms of matrices. I don't like to think in this way but I often must. I am building systems and databases in my trade and, as I said in a post earlier today, things either fit or they don't: they either fit into a/the matrix or they don't. It is not my INTENTION to think in these terms but I must on many occasions. Things have to boil down to a matrix.

I know a PM who is very good and talented at his craft and he frequently likes to put things into matrices. I think he overuses the tool in fact. When I'm building systems, many matrices are required. But I don't want to burden the customer or my peers with this extremely rigid way of thinking. Thinking in METAPHORS is much easier but not always possible. Asking questions and developing a mental model for MYSELF is often good enough. "Requirements statements", rules, and policies are often good enough to be clear. Knowledge can be represented in very many forms and the matrix represents just one. The world is not a database and never will be.

If you are a matrix-thinker, or a matrix-over-user, or are required by your line of work to be a matrix user frequently, consider your audience and use matrices and matrix-like-thinking sparingly. People are systems, not spreadsheets. Use a variety of methods and don't think of the world as if it will all ever fit into a/the matrix. It won't, so give it up!

Constantly Improve the Interface Between Your Change and Presentation Layers

Make a very clear distinction and separation between your "change layer" (that which changes, is variable within your business, etc.) and the presentation. That which is quality, confident, and customer facing. Decouple these things and separate them at all costs. Be consistent with customers and constantly work with your trusted team to clearly define and improve this interface.

Capture and Surface the Waste in Your System

Let's say you're building a system with a few inputs and a lot of outputs. They system is complex. You know that "garbage in garbage out" is true but there are also wastes within the system itself. Say you have two garbage inputs and want to make a good system. So the saying would be "garbage in, gold out". So if some of the garbage is gold, then how do you differentiate the two? You have to squeeze the garbage out and demonstrate the gold. You only know the gold is gold because you know the garbage is the garbage.

Tweak and Improve the Model

What is the model? Who cares about it? The model to me in work and business is the shared mental understanding between service provider and customer about what the current problems are and what possible solutions are.

A "good model" is shared and exhibits a few other key properties: resiliency, constant improvement, change, innovation, and frequent new insights and enhancements.

A "bad model" is one that is stagnant, one-sided, confusing, unclear, unshared.

I'm working on a project for a client right now that in my opinion has a "bad model". I am building the product and model that represents it and it is currently bad because I think I am the only one that understands it. This is the worst possible place to be in; but also potentially the strongest if you understand it and communicate effectively about it. Getting to this place of realizing a "bad model" comes from poor communication, lack of mutual understanding, poor collaboration, or a fullness of delegation and lack of care. Hoping for miracles will not create good models by itself. As I improve this "bad model" into a good one, it is my hope that the customer will start to realize that the bad model can potentially be good if we decide to build it together; but it requires cooperation and partnership.

We have to build a better reality with each other. I cannot build something "for you" without your input, knowledge, needs, or voice.