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.

Making People Make Decisions Is Risky Business

When you're designing a system or database, you can't have ambiguity. Things either fit in the database / model or they don't. You can backlog or table things that don't make sense but you as the system engineer have to know what's going on. You have to listen to the users and customers but you can't make concessions that break the whole system. In this way you have to be somewhat forceful with people sometimes to "make them" make decisions.

How is this possible or why is this possible? I don't know. Force of will? I believe in my consulting work some people really don't like me and really don't get me; they don't know what I'm trying to do or why. They may see me as inflexible. I can understand that. But I'm building a system and it has rules. I only know what I do and not know and am not willing to integrate concepts and ideas that cloud my world view. Sorry if this is selfish, strange, or anti-social but this is the way it is.

Do you have different ideas of how to design collaborative systems? My goal, in the end, is that the systems are collaborative and software based; that Eric Veal is not a part of the system, rather a facilitator to that which is OUR system. I am just a facilitator. Good processes will make the system go, not Eric Veal.

I’ll Learn It at Some Point but Don’t Need to Now

In database programming, I frequently use "views" to solve problems. Views have limitations, especially when you use "SELECT *". If the underlying schema is refreshed—at least in SQL Server—the data gets out of whack. I really want to figure out a better way of doing this; and I'm sure I will at some point…but I don't have time right now. Since I know how to make this method work (with all of its warts) I am okay to operate using this method because I know what I don't know.

Hopefully soon I'll learn how to work around this problem; either by automatically refreshing my views or by learning more about how to use SQL CTE's (Common Table Expressions).

“Give Him a Chance to Think”

I want people to think of me in this way. Not revered, necessarily, but respected; thought of as someone who requires time to think and when he is provided it, he comes up with good ideas. Sometimes the idea will come immediately, as part of conversation, and sometimes it will come hours, days, or years later. This is the type of "mental space" I would like people to provide me. It will be work for me to get to the place where I can expect and get it.