Crazy Making

So much for my great ideas about bridging the gap from back end to front-end. I'm now way back in the back end, creating some extremely old school hack because the middle tier wasn't working right. BOOOOOOOOOOOOOOOOOOOOO! Here's how to have an OUTPUT from a Stored Procedure that uses Dynamic SQL.

CREATE
PROCEDURE Myproc

@parm varchar(10),

@parm1OUT varchar(30) OUTPUT,

@parm2OUT varchar(30) OUTPUT

AS

SELECT @parm1OUT='parm 1' + @parm

SELECT @parm2OUT='parm 2' + @parm

GO

 

DECLARE @SQLString NVARCHAR(500)

DECLARE @ParmDefinition NVARCHAR(500)

DECLARE @parmIN VARCHAR(10)

DECLARE @parmRET1 VARCHAR(30)

DECLARE @parmRET2 VARCHAR(30)

 

SET @parmIN=' returned'

SET @SQLString=N'EXEC Myproc @parm,

@parm1OUT OUTPUT, @parm2OUT OUTPUT'

SET @ParmDefinition=N'@parm varchar(10),

@parm1OUT varchar(30) OUTPUT,

@parm2OUT varchar(30) OUTPUT'

 

EXECUTE
sp_executesql

@SQLString,

@ParmDefinition,

@parm=@parmIN,

@parm1OUT=@parmRET1 OUTPUT,@parm2OUT=@parmRET2 OUTPUT

 

SELECT @parmRET1 AS "parameter 1", @parmRET2 AS "parameter 2"

go

drop
procedure Myproc

Close the Gap Between the Database and UI

This is no small feat to overcome and to do it means that you can build an entire software application by yourself; all tiers! Not relying on the DBA, Designer, and Coder roles, but on you as the focus in the role(s) of Architect/Manager/Producer. I wrote years ago about "top heavy" applications that repeat logic in the model, views, and controllers. I'm hoping that today we're closer to having the Model Driven Architecture gap bridged: the holy land of software!

Going with the Flow and Being Flexible

Say you create something really great and people like it. You show it to them and they want more. They want to help you build it and work on it. You may have started as "that guy" who was doing some random thing, but depending on how you play your cards, you could become "THE guy" who is at the center of it all. Follow your products and creations around; see where they take you!

In Software, You Can Harden and Tighten Your Design Later

I said it earlier, but don't be a perfectionist in what you create. Don't make the first product you produce perfectly right and tight the first time. Leave some room for enhancement and improvement. Get a working product in their hands as fast as you can and fix what's broken later.

<Rant> The “Cloud” in Cloud Computing is a Stupid Name

Come up with something new, people! It's like saying "fog". People are foggy and cloudy on the cloud. They don't know what it is. I don't know what it is (in total) and I think I should. That's a problem if you're trying to sell someone something more than snake oil. Let's start offering real value and get clear on what the cloud—or our service in the cloud—is!!!

Refactor Later If Necessary

Don't be a perfectionist about the software you're designing. There's always another time you can come back and fix what you built. That's the beauty in fact about object-oriented or component-oriented programming is that the components are "swappable". If I messed something up this time around, I can always go back and fix it later. Insist, however, that the STRUCTURE you create is very good and that you have a solid, defensible, base architecture to stand on. Be fine with rafactoring later if you have to; you'll probably have to.

Be Cool Under Pressure

Sometimes you have to deliver rapidly and set expectations with people. You could burn yourself out and work 80 hour weeks or you could take it easy. Be cool, confident, calm and don't burn yourself out. Make reasonable commitments with people if at all possible.

Get Refocused

I feel distracted at the moment. My main project at work is out of mothballs and I'm trying to get things done on it. The learning curve on Silverlight, RIA Services, and passing data from SQL Server isn't easy. I must plod forward.

The Librarian Role is Needed

In companies there needs to be a librarian or secretary. Teams are busy and produce a lot of things. Even with good IT systems, things don't get checked in and project results or artifacts stay on local machines. This is a knowledge management problem when the resource moves onto something else and frequently causes rework. I propose the role of LIBRARIAN. This person would make sure that everything is done. This is a hat the project manager or functional manager could manage.

Lots to Learn in Programming User Interfaces

It takes a long time to get good at programming. I still don't feel like my "toolbox" is working very well from the front-end to the back-end. I am stronger on the database side and now I have to bridge the gap up to the UI. The UI technologies are crazy in my opinion. Silverlight and .NET RIA Services are compelling. I like how they're working with data binding. .NET 2010 seems to have some cool data binding "drag and drop" functionality (see http://channel9.msdn.com/posts/kmcgrath/Silverlight-Object-Binding-in-Visual-Studio-2010-Beta-2/). ASP.NET MVC is different. I'm more familiar with HTML as my UI and JQuery is a very nice extension for that… Windows Workflow Foundation (WF) is another that I'd like to use here to figure out how to handle the different activities in the workflow I'm currently designing. Another cool / promising technology is .NET Entity Framework. Looks cool and now there's going to be SQL Server Modeling Services and a language called "M". So much to learn!!

Defer in Order to Manage Multiple Customers and Interruptions

I've had the luxury for about three months now of working on projects that have been generally serial in nature. That's changing a bit as I've finished a few things and they're in peoples' hands.

I'm going to implement a new personal policy that is to start and finish the highest priority thing as soon as I can "reasonably wrap up and mothball" what I'm currently doing. I'm currently working on an app that is due in a few weeks. I'm going to finish any loose ends, write down my next steps and move onto the other more pressing thing now. I'll dredge up the other project when I'm done with the current one.

Ideal Software Development Manager

Listens well, writes code, willing to help, willing to be interrupted, not too busy or randomized by other things, values you, smart.

Plan for a Longer Review When the Next Task is Big or Important

I have a problem that I'd like to share with a coworker to get his input. He's really the customer on this so I don't want to waste his time. I have to get ready to ask the question and engage him. This particular question I want to be reasonably BIG because I want to spend some time with him designing the next mini-sprint or story I'm working on; really the finish of this iteration of the product: the first prototype! I've basically finished my current story "build middle tier" and now I have to work on the next story "enable front end". The new story is pretty complex for me and I don't know much. He doesn't either. I could start in on it and ask him things as I go, bit by bit, but I may ask now, show him what I have so far and step into the next big problem, chartered and re-energized by him.

I'm an idealist and want to have shared mental models and designs between people. I don't want to work alone but sometimes I do and have to. This is the case now where I want to take the risk of engaging the customer so we can co-visualize and plan the last leg of his/her project. I don't want to annoy this person but I want to keep them engaged and involved.

Back-to-Front vs. Front-to-Back Systems Design

We all think in models and our computers allow us to build models, so of course use them, right? It would be ideal to have a model of our system that we instantiate. We draw something or configure something and a system comes into existence. That's the basic practice of development but it's much different and far more iterative going from front to back and back to front. Writing code is a sometimes aggravating process as you validate your coding concepts against your mental model of the ideal (or good enough) solution. The Model-View-Controller pattern is very popular these days with Ruby on Rails and ASP.NET MVC. These solutions allow developers to pass data between the layers and control how things are presented. There's a flow they have in mind and that's a really handy tool! I'm building a Silverlight UI right now and I'm preparing the underlying data model for on-screen display. SOMEHOW I have to sync up the back end with the controls and intended user scenarios in the front end. That's tricky. I've been working from back to front but now I'm having to go from front to back. Somehow these worlds will collide!

Computers will be better when:

When software engineers figure out how to allow a user to drag objects around and relate them to other objects in many flexible ways (not just hierarchies), computers will be way more powerful.

Enjoying the Tranquility of Authorized Research

I was obsessing yesterday over the idea that I didn't know how to do "data binding" in .NET. I wanted get help from my coworker because I thought he knew about it but it turns out he doesn't. I talked to him this morning and he told me to do the reading and research necessary to "get 'er done". Cool! So now I get to become my team's resident expert on data binding in Silverlight on .NET. I'm looking forward to experiencing the tranquility of learning something new and want to learn, at my pace, on a cool project, at least for the moment. Thanks, V!

Refactor Later

Start and finish your design. You may not know exactly how to do it but you need to finish. Surely you can engineer a way to make it work but don't get bogged down in asking too many people for input. Maybe don't ask anyone for input at all. You can get the input later when you finish and at that time, either enhance this creation or the next one.

Some preferences don’t matter; they are for you

Sometimes you may think you want people to offer input on something you're designing but you typically don't need this. Keep steaming ahead and make decisions about the design as you see fit. Be creative.

It’s better to ask for forgiveness than permission

Authorize yourself to do something really good today. Maybe the others won't like it, but finish it and make it tight. Show it to them and gauge their reaction. Without a doubt it will be a learning experience.

Don’t be parochial, get the job done!

I've blogged before about how you have to wear different "hats" to do well in IT. I think the hats are: project manager, program manager, product owner, customer, developer, and tester. That said, as a consultant (or employee for that matter!) the "that's not my role" mentality is completely retarded. Don't do it. Wear many hats and don't develop a not invented here mentality! Make sure you develop skills in all of these disciplines and figure out how you can get the job done if you're given any of these tasks. Learn from the masters of these roles and be the "project manager" to drive toward getting the job done. Don't be parochial!

Training Product Owners Is Challenging

Customers can be difficult of course. I say this because many people might not know what they want or how to get there and your job as a software development consultant or team leader is to communicate with this person as effectively as you can and give them products that they can use in THEIR processes. Some core skills and lessons that you need to teach the product owner (whoever he or she may be are): 1) software development is difficult 2) there is uncertainty in how the solution will be exactly created and knowing what exactly will come out is a minute-by-minute problem for a software developer or leader 3) estimating when you'll be done is difficult 4) there exists a process of continuous improvement and improvement of the customer relationship. That process referenced in #4 is YOU!!!

Waterfall doesn't work a lot of but it's fine to have frameworks and principles that you follow. CMMi, Six Sigma, Agile, PMBOK, MVC, etc. They all matter. In the end, something has to get done and agile is a way of breaking up the problem FROM THE BEGINNING about what needs to be done next. What's the risk? What's the priority? Can we do it? When do you need it? Removing as many of these impediments as is possible as fast as you can is the way!

I Learned a Lot About Software Development and Communications from Scott B.

A former coworker, Scott Brown, knew Agile. He'd lived it on the CodePlex program at Microsoft. I wasn't a current practicing developer at the time I was ScrumMaster of that group but I am now. I probably learned the most from Scott. He was very pro-Agile; a zealout, I'd say, but retrospectively he knew a lot about the process and effective communications. He was all about velocity and getting things done; pragmatism. Our team wasn't probably ready at the time for that level of engagement (I know I wasn't) but I am now.

Thanks to Scott for showing me how software development can be fun and we can reduce randomization through quality communications.

Get to a working demo as fast as you can!

You can potentially be perfectionistic and want what's perfect for your app but in the end you have to release it to users and let them break it. Think through the risks and issues of the scenarios they're going to do and plan for that. What are the scenarios? How will you know that they're working well? Answering those questions should be the input to your sprint and its "definition of done".

Cautiously Demo Your Work to Build Relationships with Customers

Caution is the key word here. You don't want to bore people. Let me explain:

The purpose of the demo (or asking for help, input, etc. from your customer or manager, teammate, etc.) is to impress upon them, and to build your relationship with them as much as you can. The more they like you, the better off you are; the more they'll like your products most likely. The more you waste their time with triviality or demos that suck, questions that are obvious or that you could have answered on your own, the more you'll turn them off, bore them, and generally make them dislike you. Sure, they may care about you as a person but what they really care about AT WORK is the product and its QUALITY. If you demo boring stuff or unfinished things or things that simply confuse them, they'll disengage and possibly dislike you, probably ignore you. They'll avoid your products as well. You don't want that.

In total, THINK HARD before you ask someone for help or look at your work. Be in control of what's being presented and don't welcome scrutiny or doubt in your approach. If the demos are good and you get the kind of feedback you really needed in the first place then you'll be in the good! Avoid "ringing the bell" at any given moment; bang the gong when you're ready to summon them!

BI Happens at the Intersection of Project and Process

You need static structures like policies, processes, roles, artifacts, and departments to be successful. Something must be core. These static structures are the tools that allow you to get things done. They are the platform. Projects on the other hand are the vehicles that do the work. If you do a lot of projects you could see project management as itself a process. But it isn't the only process yet it is a very central one.

Business Intelligence As Feeding the Hungry

The business is hungry for information about their operations and customers. The data that is around the business is not currently very delicious or available. People are picking at scraps all the time but they are definitely not satiated. Business analysts, project, product, and program managers (cooks in my scenario) are hired to prepare data-meals for the very data-hungry executives and managers. The managers are picky eaters and have high expectations of what you put on their plate. The job of the cook/analyst is to gather up the various bits (data-ingredients) and whip them into a lovely broth that the business can enjoyably consume.

What’s the Difference Between a Project and Process

The CEO of Siemens Ultrasound asked me once, "What's the difference between a project and a process?" My answer was, "The process is how and the project is the what." He disagreed and explained to me through an example: "If you have never driven from San Jose to Los Angeles before, that is a project, but if you do it over and over again, then it becomes a process. So a project BECOMES a process over time, with repetition. A project is something you have never done before [or have done infrequently]." I totally disagreed.

What are your thoughts on these differences?

I would say now (and said to him then) that a project is an INSTANCE of a process and that the process is continuously improving and changing (it's the how).

Produce Waste Intentionally in Your System’s Design

As part of the design of a quality system, you will encounter ways to be lean and you will encounter ways to create waste. Part of a you will want to keep everything (hoard) and part of you will want to keep only the things that matter. If you keep only the things that matter to you now, then you are potentially painting yourself into a corner. If, on the other hand, you design such that you have some waste (are not perfectly efficient) such that you can pick up the pieces that you left behind.

The point here is that you have to design systems that have some waste, such that it can be consumed later, by others. Designing perfect systems is impossible and if you were to do it, you'd have others pick and find holes and they'd have a job and you wouldn't. Or you'd be starting over somewhere from scratch. Go agile or go home.

What’s It Take To Be a Senior Developer or Software Leader?

If I were to trumpet my own horn, I would say that I've been building web sites and technology-based human process workflows for the last 13 years. Since I was 19 years old and was using Microsoft FrontPage. At the time my skills were HTML layout, PhotoShop, and CSS. I was mostly a designer. In 1999 I picked up the skill of SQL database development and object-oriented programming. That was a huge leap forward. I was writing server-side scripts in 1999 and did that professionally for about 4 years. Then .NET came out. Then I went back to school and got my Master of Science and MBA in Information Systems. I learned a lot then. In 2002 I learned about and implemented SharePoint and was a CAML developer. I worked with OpenText LiveLink and IDS Scheer ARIS to design enterprise wide SOA and Knowledge Management architecture for Siemens Ultrasound Division. I left there and spent the next few years working with SharePoint Server (MOSS) and did the same: this time for Nordstrom and Microsoft. I became a software development project manager and then started getting back into writing code. The languages of today: C#, SQL Server 2008 (I started on 2000), ASP.NET MVC, SilverLight, JQuery, Drupal, WordPress, and I'm getting into Eclipse.

At any rate, I would say that a senior developer is a person who can:

• Write code
  
• Think of processes and business problems as software systems
  
• Can lead software development teams
  
• Is highly communicative and understand the software development process
  
• Can recruit and is respected by other software developers
  

Thoughts?

I Know About Collaborative Tools

The infrastructure exists now for any small team to form online and connect and build software and create companies and "communities of practice" for very little money. Only corporations had this infrastructure a few years ago. You just need the knowledge and social / networking skill to do it. So do it!!! (Or ask me how to do it, I'd be happy to help you!)

How I’m Going to Change the World

Two ways:
Through consulting with businesses and organizations and having an hourly wage or retainer from them as a "worker" or resource to them.
Through making software products or creative processes/systems for companies or for myself that I monetize somehow.
All while having fun.

How I Update My Blog, Twitter, and Facebook

I generally assume that I'm going to blog everything (since I'm generally a long winded person and you never know how deep and long-winded a thought is!). I open up a new Word doc as my blog and start writing. If I determine it's just a short statement (or better as a short statement/point), I'll Tweet and/or Facebook update it. I generally tweet nerdy things to Twitter and other silly musings to Facebook; this may change over time but my Facebook is "friends" and my Twitter is more business-minded. If what I'm writing is long, I'll try to write it all out. If it's short enough and concise enough, and what I think to be interesting and/or pertinent enough and that I want to publish it, I'll post it to my blog. If it's too long or boring, or in concise or rambling (like this post? J), I save it, possibly to return to it later (write a book?) or simply round-file it.
It's nice to have these different online communities and audiences and communication modalities of micro-Blogging and real blogging for sharing your thoughts.

Facebook IM Scam. Beware. I sure hope this wasn’t Madhu!

4:31pmMadhu






hi?





4:33pmMadhu





u there?





?





?





4:36pmEric





Hi Madhu.





I am.





4:36pmMadhu





am not good Eric.





4:36pmEric





am not good?





what?





4:37pmMadhu





i'm stuck here in london and i need help with flying back home.





4:37pmEric





Okay. Tell me more. How can I help you?





in what way are you stuck?





4:38pmMadhu





i had to visit a resort in london on vacation and i was robbed at the park close to the hotel where i lodged





4:38pmEric





Okay.





I'm sorry to hear that.





Do you have anything? ID, etc.?





Are you safe now?





4:39pmMadhu





i was mugged at a gun point and all cash on me got stolen including my credit cards and phone.





4:39pmEric





Okay.





Do you have any documentation?





4:40pmMadhu





the good thing is i still have my passport with me.





4:40pmEric





(as in ID, passport, etc.?) have you visited the US Embassy or anything like that? Are you a US citizen?





That is a good thing!! :)





Have you been able to call your credit card companies to cancel them?





4:40pmMadhu





all i need now is help in getting a return flight ticket back home from you.





4:41pmEric





I see.





And when could I expect repayment? :)





4:41pmMadhu





I need $500USD for my return ticket fees.





i will pay you back as soon as am back home.





4:42pmEric





Remind me how we know each other. :)





Madhu?





4:43pmMadhu





if i wasnt the one i wont ask you to wire to my name as we both know i will need some kinda of identification before i get the cash at the bank.





4:43pmEric





Please tell me how you know me specifically.





4:44pmMadhu





we are from the same city.





4:44pmEric





Yes, please tell me more, specifically about you know me. Who am I?





What is the nature of our relationship?





4:45pmMadhu





Look Eric,this is not the time for Question.





i need to leave,if you are not helping me





4:45pmEric





Madhu, what is your profession?





4:47pmMadhu





i need to leave now.





bye





4:47pmEric





Tell me anything about how we know each other and your profession or mine and I'll talk.





4:48pmMadhu





if i wasnt the one i wont ask you to wire to my name as we both know i will need some kinda of identification before i get the cash at the bank.





bye





you are my formal friend





4:49pmEric





I know you are not Madhu and this is a scam and "formal friend" is not a good enough answer. You should be ashamed that you are trying to rip people off. You should go look for a job instead.

Emerging from Your Work and Selling Simple Solutions to Complex Problems

I'm argumentative and hard-headed by nature. That's probably an understatement. Really, I'm pretty much a pain in the butt. But I try to be funny and have a sense of humor. I try to have a good time. I try to be thoughtful. It's my hope that some people will like me, listen to me, and be willing to put up with me for long enough to allow me to tell them what I think about a problem I'm solving. In short want them to buy into me and what I'm selling.

At work, I'm producing a complex analysis of what happens when people log out of Hotmail and use other Microsoft properties. I'm trying to find out some patterns. There are dozens of parameters and variations of the process. I need a simple way to measure it so I can explain it clearly. I've spent about a month working on this now and have been improving my methodology on it. I think I'm getting close to having a robust solution to the problem I've been given.

The next step for me will be to teach people what I did and how they can use it; to promote myself and the product. I want the interested persons to BUY INTO me, my methodology, and product. Only if I've made an elegant solution can I accomplish this. It's not all about personal power, it's about QUALITY. If things appear to be complex or unfinished, people will look the other way.

I'm still in development mode at the moment but I hope to emerge from this state soon in a highly effective and communicative way that allows me to advocate the greatness of my solution.

Separate Your Concerns

Build to the bare minimum part that will serve as an input or foundation to some other component. Don't build 'one-size-fits-all' systems that do everything or serve too many functions or purposes. Componentize!!!!!!!!!!!!!!!!!!!

Dividing Up the Work

An important part of being Agile and enjoying your team is efficiently and effectively dividing up the work. This includes figuring out the roles of each team member (as a function of the current work load) and also how they will collaborate with one another and their stakeholders in general. It is also the responsibility of each individual team member to determine how they can best impact and support the team's overall quality and acceleration (velocity over time) ie performance. People need to have autonomy so they can achieve things and learn on their own, but also need to be provided incentives to collaborate and interact with their team for the team to grow stronger over time.

I’d Like to Find the Perfect Work Partners

I want to work, play, and collaborate with people who are:

• Inquisitive
  
• Playful
  
• Fun
  
• Intelligent
  
• Funny
  
• Available and willing to give time
  
• Thoughtful
  
• Curious
  
• Courageous and strong
  
• Supportive
  
• Good coaches
  
• Good listeners
  
• Creative
  

It's hard, sometimes, when you're stuck working alone. Our best work is rarely done—if done at all—when we're alone. We have to band together and find others who complement us or lift us up somehow; motivate us, change us. I think there are people out there who can help us with most of our needs, regardless of the task. They are generally playful and fun. We need to seek these people out and create with them.

Sprinting at a Sustainable Pace Seems Oxymoronic

I had my primary customer tell me today that my current project should be done by next Friday. I'm fine with that but I have no idea how long it will take. I'm not stressing, either. I told him that I'd sprint on it and give him daily updates, letting him know how it was going. He said, "Don't kill yourself, it's okay [if it slips]." (I have a very kind customer, mind you). The customer must have thought that if I'm sprinting daily, I'm wearing myself out. This isn't true. I'm still having fun and I'm still putting in my standard 8-hour work day. I'm head's down on the project and moving forward as fast and reasonably can. If I determine at some point soon (as fast as possible) that this assignment is mission impossible, I'll tell him, he'll know. My customer's not trying to burn me out and I'm not trying to burn myself out but I'm still trying to dig into the project as it's described as fast as I can and start to move forward so I can determine the velocity of this sprint and if it's tracking with our 1/29 due date. Let's hope it is!

Things I’ve Learned Since November

• How to attach to a process in Visual Studio
  
• Source Code control with Source Depot
  
• Integrating source control with Visual Studio
  
• Hosting SVN online
  
• The SCOPE Language
  
• Running database jobs on a Cluster
  
• Processing usage logs
  
• Coding through SIPOC logic (Supplier, Input, Process, Output, Consumer)

Code for the Retrospective

Your goal as a developer is to get the job done as fast as you can—to the requirements—and have your retrospective with your developer buddies and the customer. You'll want to bring a few things to the retrospective and be prepared to get the most out of it:

1. What went well
   
2. What didn't go so well
   
3. What you'd like to change
   
4. Your code base and what you produced as far as diagrams, lessons learned, tips, tricks, etc.
   

The retrospective may be your only chance to complain a bit, kick up your heals, be thankful that you're finished, learn something, and re-energize yourself for you next task. Enjoy it and plan for it.

Code for the retrospective.

It’s Not About You. Keep a Sense of Urgency.

When you're working on a project, you can decide to do things the smart, elegant, research-based way, or you can do them in whichever way is necessary to get the job done. To me, a project is and should be a "forward pass" sprint through the requirements. A project isn't the process. A project isn't fair. It is a single iteration. There will always? be time for more improvement and change later. Maybe you won't get to change what you want to on this project, or learn what you want to, but you can do this next time you have the opportunity. In a project you solve the problem as fast you can and backlog the opportunities for future consideration. You deliver. Maybe the things you didn't do won't be considered, maybe they'll never be done. But you will still always have the idea to apply that thing some other time. Nothing is lost.

I recently ran into a scenario like this at work while trying to "lookup" something against a file. The way the existing code was written, it only worked on one file, but I had two files. And I needed a solution. We determined that since I had just two (and not 300, for example) files, that we could copy the code and make it work. This was the fastest way of doing it and we know we'll try to do something better in the future.

Engineers have to make things work. There is urgency, there are customers, the project is held down every minute you're not solving the key requirements. The world is not about you and your learning, nor is it about an elegant system. Those things are for you, your values, and in your long term, maybe you can achieve them. But for now, it is about getting the job done. The system will take care of innovation, not you now.

My Business Areas of Focus for 2010

I'm going to focus on four main (business related) things in 2010:

1.  Network
I'll network because I have to meet new people and develop a support system of people who know me and what I am doing as well as what my needs are. I am going to do this during the days.

2.  Engineer and Build products in my free time and work with people online
I'll engineer and build new products in my free time because I have to. I want to develop my skills and I want to create new products and services. I want to stay current on the new technologies and be a builder. I want to run the risk / opportunity of making something that is cool, will grow, and is a business. I want to get traffic and make a buck. I won't do much in my free time that is not for business (besides the necessary R&D required to accomplish business objectives).

3.  Make personal income
I'll make personal income and keep a day job. I am going to work for someone. Networking and doing well at my day job will help me accomplish this. My side projects will hopefully help me be good at what I do during the day. Whether I am a 1099 contractor, a W2 employee, a consultant, contractor, or employee, I am going to do well.

4.  Volunteer
I'll volunteer and work on some things for free. Not out of the "kindness of my heart" but out of the desire to learn and connect with people. If I offer things for free, I will learn, I will feel good and I will develop a more flourishing network.

In addition to this stuff, I'll exercise, hang with friends, watch my budget, have fun, read, be outdoors, travel some, relax, spend time with family, and enjoy myself.

That's the plan! Let's get it on.

3 Ways to Value Nothing

Sometimes you want to calculate usage growth rates for people who are brand new. There are three options for doing this. They are:

1. Throw out these ones and keep the ones where there was previous growth.
   
2. Set a standard denominator based on the bottom. (say 1 or 0.1 or 0.8 or something)
   
3. Set a dynamic denominator based on the top. (Say new value – 2 or new value – ½ of new value)
   

These options show that there is ambiguity in how you value new users with possible small amounts of usage.

I'd recommend that you do this in all three ways; changing parameters in the second two and see what you like, given your risks and business purposes.

List of Data Visualization Tools

Just got "Now You See It" by Stephen Few.  Here's a  list of the tools he's using to generate good-looking visualizations of data in the book:


Panopticon Explorer


Time Searcher 2

Tableau Software

Inxight's Table Lens

Spotfire

Vizster

JMP Profiler

Trixie Tracker

Google Motion Charts

Red Balloon Winning Method

Really found this contest interesting and exciting.  MIT won it.  Their technique: divide the total pool equally between the outcomes.  Give 1/2 to the winner, 1/4 to the person that referred the winner, 1/8 to the next, 1/16 to the next, and 1/16th to charity. 

That to me is  kicking positive butt but they didn't keep any money for themselves.  But they're rolling in the acclaim and accolades, so I'm sure it didn't do them any harm!

Don't Just Kick Butt...Kick Positive Butt

In this post, I explain my two core business principles: Kicking Butt and more importantly Kicking Positive Butt.  Briefly, the point is to do good work for the communities you care about but in order to do that, you have to get out there first.  I hope that me sharing my principles with you will help you better understand what your principles might be. 

My overall philosophy is pretty simple: Kick Positive Booty.  But this has a sub-part to it and is really TWO steps: Kick Positive Booty (principle 1) requies that you first Kick Booty (principle 2).  Together these principles focus and balance me toward getting things done.

1. Kick Booty - First you have to get out there and connect with people.  This means getting off your butt and taking charge of your life.  You have to be hungry, aggressive, and focused and ready to change things and take them as they come.
   
2. Kick Positive Booty - For me, I don't want to just "kick butt", I want to kick good butt.  A specific type of butt.  I want to do good for mankind and society first, and myself second.  I care fundamentally about myself and my situation but if I don't put others in front of myself and their needs in front of mine I will not be successful.  This is like having good customer service and not being too self-serving.

In summary, you learned that I'm not just about kicking butt but I want to kick positive butt and make a change to things that matter.  I hope that knowing this will help you think about what POSITIVE butts you are going to kick!

An Easy-To-Follow, Scalable, Agile Process for Anything

In this article, I outline a quick and easy-to-follow process for getting lots of things done (the agile way).  I think you'll find it useful and informative.  It doesn't matter if you're scheduling improvements to your home, hometown, or business, you can follow this process on any and get results. 

1. Note the request(s) (high level) in the backlog…you don’t have to understand what it is fully…just the gist of what’s being requested.  Make sure you include who its from and anything else.  Make sure it's fluid, too, and always be willing to go all of the way to the end of the process if the rules allow.  Don't let yourself or the process be the bottleneck!
   
2. Backlog and prioritize this work.  Figure out where the request should sit in the queue.  Use a method like FIFO or LIFO as a reference.  You could also create a "value index" to score the cost/benefit of the request.  Sometimes you may choose to do ANYTHING you can just to demonstrate value and show the customer that you are doing SOMETHING toward their objectives.
   
3. Define the request in concrete terms including the problem, required output and success criteria.  This may also include the specific implementation method and input required to get the job done.  Be clear what the customer needs and make sure there's a clear agreement and understanding of output at this time.
   
4. Optionally train the person(s) performing the work—even if it’s yourself—how to do the tasks necessary.  Remember the goals and make sure there is no "loss" in the communication process. 
   
5. Assign the work and start executing.
6. When the work is reported to be completed to spec by the person, verify.  Repeat this step until you accept the quality. Note: you could see all changes you make here as backlog items as well, so beware of "churn" and be fair to the people and process (team!).
   
7. You may queue or hold the result at this time as to efficiently deliver a collection of things to your customers or you may deliver it as well.  Queuing your results will promote longer, larger cycle times but could be more efficient for your business.  Delivering now will shorten the cycle and create for much higher customer interaction, which can be good, especially for very small teams (even teams of one).
   
8. Deliver the result to the end customer.  This is a similar verification (validation?) process but is facilitated by you, the process owner; that way expectations and feedback can be set and the overall process and deliver method improved.

I hope you found this process for getting things done useful and are able to apply it to things in your life.  Please offer any feedback or questions to me through the blog or to eric.veal@efficitrends.com.  Thanks!

Be Versatile or Be Gone

One of the keys to being a high-functioning technology consultant is to be versatile in your role.  You have to be able to do a lot of things well to make the client happy.  Common roles you (should) have to play well are Analyst, Builder, and Project Manager.  Here’s a quick description of each:

Analyst - Understand and define the problem using your skills of interviewing, math, statistics, process flow, data and information analysis.
Builder - put the necessary pieces together to create the solution.
Project manager – Integrate and communicate what’s necessary about the related parts of the project such that the involved parties understand what’s going on and continue to want what's being produced.  

In total, you have to be willing to do whichever job is necessary to get the job done and make the customer happy.  This requires experience, risk-taking, research, and networking.

6 Ways I'll Make a Better Professional Blog

I recently wrote a blog post (here) that I shared with several people.  Some liked it and were "with me" yet others wrote somewhat lengthy feedback about how I needed to improve my delivery method.  They were commenting more on my style more than the content.  So I guess I'll focus on style for the moment. 

Here's what I'm going to do about it.  I hope you'll take what I'm  learning and apply it to your own experiences writing, blogging, and career management. 

Thanks to Don L. and John S. for their feedback and insight.

How I'll Offer More Quality Content to My Audience:

1. I'll get to know my audience better and understand their needs and desires in order to offer more relevant information and conversation about the topics that interest me most. 
2. I'll be more clear about my point and ramble less.  I'll try to capture the audience's attention ASAP, get to the point and get out the information that I'm trying to convey as compactly and rapidly as possible.  Maybe I'll use more graphics (see this post).
3. I'll be more precise and specific and cite references more. I'll read more as an input.
   
4. I'll have a call to action if possible, directing my audience to next steps, further reading, engagement, etc.
   
5. I'll build a community and drum up input from them on my delivery and content (effectiveness).  
6. I'll tell more people how to sign up for my blog and think of other methods of reaching my audience (podcast, email, speaking engagements, etc.)
   

My overall goal online here and professionally is to create a dialog and debate with my audience about topics that matter a great deal to me.  I'm trying to learn and help my audience as much as I can with insight that matters to them.  I'm seeking insight from them on the topics that matter most to me and also looking for feedback on delivering the best way possible.  Thanks for your patience and participation in this process.

8 Ways to Be Agile with All Customers and Grow Your Business

1. Say yes to all work being requested, regardless of your ability to deliver on it now
   
2. Seek to define all work completely with success criteria, method, etc. and add it to your backlog
3. Make your backlog/pipeline visible and available to your customers
   
4. Make it clear to your customers what you're working on now and next
   
5. Have your customers prioritize your backlog and "fight" amongst each other (you should probably facilitate this so you're not purely randomized) for your time, driving up demand
6. Work on and complete the well-defined problems and learn from the experiences.  Feed lessons learned and changes back into the backlog.
7. Make customer after customer happy and make sure the the prioritization method is fair and best for your business and total customer satisfaction.
   
8. Try to delegate as much work as you can to your team but make sure that the process documents all work, regardless of who does it.  

Your value is how much you are getting done in total, though your system.  This means that you should be developing more business, working less, defining more.  You should focus on the demand AND supply side and grow this business.

Refusing to Use the Tie-Breaker Role

My friend Bruce today told me about a book called The Seven-Day Weekend: Changing the Way Work Works http://www.amazon.com/Seven-Day-Weekend-Changing-Work-Works/dp/1591840260 and brought up an interesting point about systems that are "open" but also have a "tie-breaker" role (manager or authoritarian).  In the system that Bruce described in the book, although this role existed, the manager never used his power as tie-breaker and would always put it back onto the group.  I thought that was interesting.

The Ideal Dev Process Parts

What parts do you think must be included in the ideal, high-scale web and software development process today?  (As judged by such factors as most Secure, Scalable, Stable, Collaborative, Clear, Easy to Use, Powerful, etc.)

I'd say it needs to have:

• For a web site / CMS:
• .NET Nuke, Ning, or WordPress
• .NET 4.0
• For code:
• TDD, unit testing
• Asp.net MVC 2.0
• Subversion, TFS, or CodePlex for code sharing
• OnTime for backlog, requirements, bug tracking, and communication
• SeleniumRC for test automation
• Team City
• For a team:
• A Digital Whiteboard

Forming a Consulting Group (that is World-Changing, Profitable, Enjoyable, Sustainable, Continuously-Improving, etc.)

The world is full today with people in business who are doing good things and making compelling change to our organizations.  These people are not generally organized as a collective.  It's likely the goal for many of these individuals to find other like-minded people and establish "guilds" around their particular part of the technology and change delivery puzzle, be it sales, product definition, development, delivery, or support.  In total, our system today requires many quality professionals to deliver the services that it has; and the quality of these services and their density is highly variable and in some cases poor, some cases excellent.  The goal is to make high-quality products that the world needs and for which the market will be willing to pay.  "It takes a village" but this village that we will need for this change is smart, involved, well-organized, and planned.  This is not a government, it is an uprising.

What are the attributes of this village we require to bring about the quality products and services of tomorrow?  From where does this village come?  The crowd, I say!  From our networks; current and future.  In my opinion, it is possible to find and support--with the appropriate tools, incentives, practices, and resources--people willing to capably contribute to our current firms and to the firms that we need to bring about.  The goal for the support organization and consulting group would be to offer the training, staffing, and project/program/product services necessary to allow the resources we have today to turn out the products we need tomorrow as fast and at as high of a quality and leading to the greatest economic value possible. The technologies we have today are mature enough to support and sustain such a group.

Today's organizations are either A) antiquated B) outdated C) unprepared or D) non-existing.  Let's fix this!


Critical Components of the Consulting Organization (EfficiTrends):

• Sales & Marketing -- responsibilities are to build the network, filter associates/partners/relationships, educate and train our stakeholders and members.
• Operations & Delivery -- responsible for getting the job done as it's defined and communicating to others when things aren't going according to plan.
• Product Definition and Contracting -- responsible for strategic planning, fine-grained management of relationships, project/program/product management, and contracting.
• Product Support and Operations, Sustainability -- responsible for the ongoing "care and feeding" of completed products and services as well as the definition of new, more streamlined ways of providing those products and services at a lower cost.

Critical Inputs to the Process:

• People in jobs
• Make the most out of the person's role and support them with a great staff and "back office"
• Provide personal marketing, coaching, and resume services about what they're doing, how to market their strengths, develop their weaknesses, and work toward demonstrable results and efficient engagement
• On-site staff augmentation and support services to fill gaps within client team.
• Project and program management definition and sales -- how to "stealthily" grow the scope of the consulting group's influence at the client.
• Replacement services when the individual isn't the best fit
• "Graceful exit" services when the client or engagement should not be the focus of the consulting organization
• Leads, hiring managers, entrepreneurs
• Assist in the definition of programs and offerings
• Put consultants and partners in place
• Seek to define measurable results and a consistent, visible practice, and knowledge base
• Partner via Master Service Agreement (MSA), Joint Venture (JV), etc.
  

My Personal and Company's Mission Statement

"To provide the best ways for people to create the most productive communities and networks about their most critical interests using the most current communications technologies."

That's it.  Any thoughts?

Eric

Developing the Right Metrics Matters the Most

There are several ways a person could view an organization:

• As a collection of business processes (activities) that the business has to perform to meet its strategic objectives
• As a collection of IT applications that support the processes
• As a collection of people and suppliers who provide the resources necessary to achieve the organizational objectives
• As a collection of metrics or measures that describe the performance of the organization

Although each of these perspectives is equally real, only one is RIGHT in my opinion. Which one? METRICS, I say. Unless we boil our organizations into numbers and shared things that people can understand -- not complex and changing things like systems, processes, tools, and people -- can we really manage our organization as a program. I'm not making an argument for ACCOUNTING, per se, I'm talking about those facts and figures that tell us whether or not our business is being successful at achieving its objectives.

Therefore, it's my contention that a key part of the strategic planning and communications processes is to define and communicate about the key performance indicators (KPIs) of your business. KPIs are a bit of a cliche term but they're critical. The fundamental question we have to agree upon is, "How will we know that we are doing well?".

The more we develop this language of numbers and measurement, the more clear we will be together on our perception of what matters and how to allocate our resources and attention.

Replacing Problems with Solutions -- More thoughts on Pragmatism

After I published my last article “15 ways to be more pragmatic at work” I started to wonder if I’d overdone it by citing fifteen points about being pragmatic. Maybe I personally wasn’t very pragmatic since it took me fifteen points to make my case!

When I wrote my 15 points, the problem that I was trying to solve for was that for me the idea of pragmatism seemed very complex and I felt that I had to create an equally complex solution (one that required a fifteen-point process) to solve for it. The basic point here is that pragmatism has a lot to do with efficiency and perception.

If the input requirement I'm given is “build a box” and I create something wildly complex like a computer, you may say that I wasn't being very pragmatic. Whereas if I instead drew a box with paper and pencil and you liked it, you may say that I'm rather pragmatic. It all depends on how we define the problem, who's the audience or judge, and what's really at stake.

When it comes to making new things and getting the most out of life, all of us probably want to know what to expect before we take something on so we are prepared to advocate or defend what we’ve done once we get to the end. We don’t want to do anything without a purpose or to have a story to tell! We know that we won’t be able to mitigate all of the risks involved in doing what we want to do decide to choose the most important risks to mitigate and go down the road to fixing them. Along the way we may have to defend our actions and tell others that what we’re doing is the right thing and the step we’re taking is the right one. In others eyes, we want to be seen as capable, confident, and intelligent; independent.

A pragmatic solution to me is one that includes only as much complexity as is required to be deemed by the people who defined and/or are defining the immediate problem at hand as acceptable. To provide for this we have to know what expectations others will have once we’re finished. This is why we have to inquire and wonder and include others on our journey. This is why planning matters and this is why it’s nearly impossible to create solutions in a vacuum.

Let’s set our sights on replacing problems we have with solutions we like.

Top 15 Tips for Becoming a More Pragmatic Worker

I recently completed an engagement leading several software development projects for Microsoft and learned quite a bit from the experience. Times are tough right now in our economy and I want to express to you how I think we all can be more pragmatic in our work styles and rise to the occasion of these tough times.

Answers.com defines pragmatism as, “having or indicating an awareness of things as they really are.” Well, how are things REALLY? I’d say—given our down-economy and business in general—the world is “really”:

• Competitive. There’s a lot of people out there competing for the same resources and business that you are.


• Impatient. Due to the competition customers may have very high expectations for what is possible and what “value” they think you can deliver to them. They want it all now, perfect.


• At Times Cut-Throat. Managers in today’s environment may be threatened by the realities of competition or the complexities of their tasks. This may cause in them agitation and desire to force workers to realize the inherent risks of today’s environment.

If we see and accept the world as competitive as described above, then we next have to figure out how we can best operate in such a context. Below is my list of top recommendations for becoming more pragmatic—and successful—in our work today. I hope you find this list useful to your situation. Please feel free to comment and augment based on your thoughts!

1. Use induction. Induction is defined as “the process of deriving general principles from particular facts or instances.” What this means to me is that we must learn by demonstrating things to our customers, ie “get real data and feedback”. Turn that real data and feedback into something real.


2. Identify and appropriately manage all assumptions. Assumptions will kill you and your organization can’t afford to run on them. Make sure you identify all of them, understand them and determine how to manage them. Some possible strategyies: a) document them and look the other way b) validate them with the customer either by asking a question or demonstrating your interpretation of the assumption in your work or c) (not recommended but sometimes necessary) cover them up.


3. Demonstrate as quickly as possible that you understand customer requests via the end product. Build as many of your unchecked assumptions and thinking into the end product so you can get feedback from the customer as soon as possible. Make sure that you are flexible in listening to the feedback integrate those changes into the next iteration.


4. Have your work process be the way that you continuously demonstrate your understanding of the customer’s requests. Be flexible. It’s okay to be wrong. Listen hard and show them that you understand through demonstration.


5. Your work backlog will grow and you need to manage it. Develop a way that you manage the things that are requested but you’re not currently doing. Expose the work backlog to your customer and work with them to set aside chunks of work that you’ll get to. Prioritize the work between what’s immediate and what’s future. Understand what’s future but don’t spend any time working toward it. Limit feedback until the next demo with the customer if at all possible.


6. Don’t over-engineer. Building too much “value” into the product will kill you. Only put in “hooks” architecturally for future possibilities but never spend too much time engineering toward them until the customer decides they are in scope. When it’s time, you’ll have a platform that makes you ready.


7. Ensure you have the right contract type setup. Using an iterative process like that which I’m suggesting is difficult. Be prepared for the rigor an negotiation required to engage with someone in such a structured and regimented manner. Make sure that the contract terms align with your goals.


8. Be clear with everyone about what the process is and isn’t. Listening, demonstrating, and responding sounds like a simple process to follow but you have to make sure that everyone gets it. Teach and coach everyone on this repetitive process so they understand their role in supporting the next increment and improvement overall.


9. Advocate less and inquire more with the customer. Your goal with the customer is to listen to their needs more and uncover more and more work that they want you to do; open up a realm of business opportunity.


10. Keep some things secret. Don’t share all of your best ideas with the customer. You may want to keep some things secret for when the time is right for a surprise.


11. Advocate more and inquire less with your team. Your team is there to support you. They need to be listened to and understood. So much innovation can come from your team if you can figure out how to integrate it and suggest it to the customer in a fair way.


12. Building products is a partnership and shouldn’t be a dictatorship. Seek to bridge the gap between all parties involved but let the product owner (customer) be the ultimate decider.


13. (Removed as it was a duplicate of a point made above. Was: "Build “hooks for the future” into your current solution")


14. Elaborate on assumptions but only when the customer thinks it’s time. Your job is to build to the “immediate core” of what the customer is stating as their need but also to add “hooks” (not total solutions, rather starting points) for what you think they could mean.


15. Use the Kano Model to think through a balanced approach with your customer. The Kano Model is a handy tool for considering customer satisfaction. Make sure you’re always doing what qualifies in the customer’s eyes but keep them excited and engaged with performance and excitement features at the same time. If you can keep them engaged enough, then not too many features should be “qualifying”.

I hope you found these tips helpful. Please offer your comments.

3 Keys to Making Your Product Development Effort Successful

Through Six Hour Startup--where a new web-based product is developed and launched by a team of 20+ strangers in six hours--I learned what it takes to lead in chaotic situations. At BluWater Consulting I was Scrum Master to three concurrent software development projects and learned that there are a few key principles required to succeed: strength, (team) commitment, systems thinking, and creativity. Based on this I define agility as “a willingness to seek, accept and integrate feedback as frequently and rapidly as possible”.

In my opinion, there are “3 Keys to Making Your Product Development Effort Successful”:

1. Develop relationships with key suppliers. Rely on your suppliers to coach you on the best tools and methods for your organization and situation. Invest the time and resources necessary to procure what’s required to lead the change you seek! At a minimum, put up a whiteboard to track each project and use “stickies” to track the work as it flows through the process. Ensure that there’s shared accountability within the team and the roles of shepherd, pairing partner, and QA are clear. Synchronize your stickie-note process with a powerful information system so you can get real-time statistics, detect, and analyze process variances.


2. Identify and establish the leadership required. The program will only succeed if you have the support and understanding of the right people. This requires persistence and a strong will! Seek to continuously understand who is in charge (the team) and govern as required. Make the roles of Scrum Master, Product Owner, etc. clear but don’t be surprised when they change.


3. Make sure that your team gets it. There are some critical things that your team has to understand before they’ll do well in an agile process. One example is understanding the difference between burning time “up” (tracking actual hours in the case of work that involves uncertainty or risk) and burning time “down” (tracking how much time is left against work that can be reasonably estimated). Make sure that your team has the training it needs to succeed, move forward, and communicate with each other effectively.

If you would like help getting your project or practice off the ground, I'm happy to quickly assess where you're at and help you get get to where you’d like to be!

Managing Schedule Risk in an Agile Scrum Process

Managing time and the team in an agile scrum project is difficult but it's gotta get done. In all projects, we have to estimate what we're going to do and try to get it done. If we aren't getting it done, we have to either work more and meet our deadline or communicate to our sponsors how things are going to be different at the deadline or move the deadline out. It's all about delivery and customer service in the end. At any rate, typical software projects have two distinct parts, each requiring their own management techniques:

1. New feature development



2. Bug fix, customer service and support

Since we have to manage both of these types of work, and they behave very differently, we need to develop a language around getting things done to support effective communications within the delivery team and to our customer community. The choice we use at my company is Agile/Scrum, where we plan and deliver our work in 2-week increments called sprints. By doing this we're able to execute and significantly re-tweak our process every two weeks. We are given a quote-unquote new lease on life every two weeks; it should be a refreshing way to work and partner.

In our methodology, new feature development is handled by the Agile/Scrum methodology burndown method to track work. The burndown method is the typical agile/scrum way of tracking work: we create a definition of done in terms of scope and features, then estimate how many hours we think it will take to do it. Between the ScrumMaster and the team, we track how the hours are burning (up or down since maybe your last estimate wasn't great and there was unseen work) on a recurring basis and if we think our velocity is what it needs to be. If the velocity starts to slow down, the team addresses how to remove impediments and get the velocity up to such a degree that the project is scheduled to finish on time. If things don't go well, we figure out how to mitigate the risk with the customer.

Burnup is a different but important concept to understand and use to manage our work. Our example of using burnup here is a 50-hour max promise to the customer to deliver customer service. We don't have to provide all 50 hours in our example but we do want to know how much of this time we're spending because it's a distraction to the other part of the project since we can share resources and sharing resources is efficient. This method requires tracking ACTUAL hours spent, which is different from the burndown method. Note that this is a key difference from burndown, where we really only care about how many hours are left. We can see how many hours are left on a burndown type of project but what's potentially left on it is certain, whereas what's left in burndown is only estimated.

These two methods of burnup and burndown are two very different ways to think about work: the former is a picture of what's necessarily remaining and the latter is a guess of what's left. The latter is best mitigated by good planning and knowledge of what tasks and how much time is required to get to "done". Together, we use these two techniques to manage risk and communicate effectively.

Conclusion: We Can Now Manage Projects That Burn Time Up and Burn Time Down

By understanding how these types of work are different and how we can manage each, we're able to develop and speak a language about risk and progress making our velocity increase and our projects more fun.

Interface of Your Choice for all Media Types

I want an API that does this:

Video.SaveAsAudio() - http://www.softpedia.com/get/Multimedia/Audio/Other-AUDIO-Tools/Free-Video-to-Mp3-Converter.shtml
Video.SaveAsText() - http://everyzing.com/
Video.Search(string TextToFind) - http://everyzing.com/
Voice.SaveAsText() - http://jott.com/
Voice.Search(string TextToFind) - http://everyzing.com/
Text.SaveAsAudio() - http://www.naturalreaders.com/

Recording the Web

Just found a free new tool called Braincast (http://www.blogger.com/www.braincast.com) that allows anyone to call a number from their phone and make a recording. The service then emails you a WAV file of that recording that you can post online. Pretty cool. Great for bloggers or podcasters! Here's a file I just recorded: http://tr.im/2xrg

How to Continuously Improve

Deming tells us to plan, do, check, then act. Is that all there is to it? Yes. But it's not that easy for a lot of people to do this. Why?

In more detail, here's the algorithm I use:

1. Plan a project or action based on your conversations with powerful and legitimate stakeholders.
   
2. Do the project or action according to plan. Do not deviate. Almost always there will be a gap between what was expected and what actually happened.
   
3. Check how big this gap is. Get feedback from the stakeholders. Note what to keep doing, stop doing, and start doing for next time. Make a plan to support what you want to keep, stop what isn't necessary, and start what's required.
   
4. Act on the plan.

Does this work for you? How do you modify this or do it differently? How does technology affect this? What tools do you use to support this process? Is there a different process? What is the hardest part about this? What makes this process break?

Planning Freaks People Out

People react differently to planning. Some like it, some hate it. Planning makes people think, commit, trust and eventually do work, perform, and risk exposing themselves. Their plans cause them to announce their intentions and make things public. That's scary for some, glorious for others.

An Answers.com definition of "plan" (the noun) is, "A proposed or tentative project or course of action." The word in the definition that I like is "tentative". It's funny because EVERYTHING is tentative! No one can predict the future or know the results. So why are we all so scared?

Expectations are another aspect of this. What do you expect? Why do you expect it? Do you have high expectations from yourself? Others? Products? Services? Things you make? Things made by others? We all have expectations but should we? Doesn't having them just hurt us? It's been said that "happiness is inversely proportionate to expectation." I would agree. So stop expecting and start planning 'cause none of us know anything ever.

It's Efficient, but for Whom?

One big problem with the "green" (environmentalism, efficiency, social consciousness) movement is that it is hard to know the truth about what is green. Hence the term "greenwashing" as in flubbing or lying about the greenness of one's product, company, or service. But is lying necessarily bad here? It could be.

It's the case in business and life that things can be "efficient" (defined by Answers.com as "Acting or producing effectively with a minimum of waste, expense, or unnecessary effort.") for one person but not another. In fact, that's the norm; there are system effects to improving one area of a process while not considering the others. There has to be a balance since there are many stakeholders and perspectives for anything we look at or touch. A simple example of sub-optimized efficiency is a company that dumps its waste into a local water supply, saving itself money but breaking the law and damaging the water supply. It's efficient for them but inefficient for the water supply, water users, etc.

Say things change and this same company decides to change its behavior and "go green". They promote how they reduced X, Y, and Z. This is good. All positive change is good, but it's still not enough. The company is not off the hook now for doing ONE GOOD THING!

The point here is that there are many SHADES of GREEN. Anything that is positive for people or the planet can be considered green but we have to be very careful what we call green or call good enough. What we should be shooting for is A BRIGHT GREEN THAT WE CAN MEASURE. That said, there's usually a the competing force of financial and economic greed. We can and do measure that well: it's called profit or loss. Where's the balance in a system like this? How would we know if we were doing the right thing? What if I made $1M from a business that hurt things and then reinvested that in saving children or streams? Am I bad?

We're All Actors

I've been thinking a lot lately about "performance". What does it mean? Here's my favorite definition from Answers.com, "A presentation, especially a theatrical one, before an audience."

I agree with this--albeit very public-sounding--definition. When I think of work I think of performance. Was the work good? Was it bad? Who was the audience? Usually your manager is witness to your work performances but sometimes they never even see, read, observe, or understand what you do. Sometimes we even get paid for performances that are not seen, heard, or used. What a waste.

I've been talking to people lately about my desire to write and speak more about my work and life passions. Blogging is one channel to accomplish the writing part but I'd also like to publish my work into other channels like journals, books, etc. To publish implies that one's intention is to SHARE his her work with an audience. The first trick, however is to identify and/or develop that audience. UNDERSTAND the audience. Who are you speaking to? What do they need and want? What are their fears and fantasies?

The more one becomes social and "out" (of their head, shell, closet, whatever it may be that's keeping them "in"), the more they act (real) and perform (well); the more they become their true selves and a key part of society.

If you're performing in a job that has a small audience and you feel like no one cares, get out of it today and do something else starting now! Grow your audience by reaching out to those around you and make a difference in your life in theirs. Let this change you take on be your NEW and NEXT performance. Make what you really love and want to do be your FINAL and REAL performance. Everything else is fake.

What's a project? What's a process?

A project is vision or plan that causes one or more people to change from doing things as they are (the current situation or status quo) to a new way (the desired future state).

A process is the current or future way that things are done.

Both human projects and processes share in the property that they require "work" to perform or sustain.

From General to Specific

ABSTRACT TERMS:
Concept, Idea, Model, Strawman, Framework, Class, Process, Template

CONCRETE TERMS:
Instance, Object, Product, Item, Implementation, Project, Realization, Fleshed Out

Where's your focus? Social? Environmental? Monetary? The work and process are what's core and what matters.

Roles of Agents in a Change Process

Generally, the roles are:

• Customer - The person getting the product or receiving the change
  


• Change Agent - The person working "both sides of the fence" to ensure proper communications
  


• Delivery - The person providing the service
  

In the case of changing a business internally, the specific roles, agents, actors are:

• Customer - The Business




• Express needs and pain points


• Adopt changes, whether originating from the business or IT

• Change Agent - Project Manager, Business/Functional Analyst




• Facilitate the discussion, negotiate, look for win-wins, and syngergy

• Delivery and Support - IT




• Develop, acquire, Deliver necessary services, supplies, and training to enhance quality of adoption

In the case of changing a market, the specific roles, agents, actors are:

• Customer - The Market




• Express needs and pain points


• Pay for products and services, whether developed from Push or Pull methods

• Change Agent - The Business, esp. Marketing and Product Managers…but everyone, really




• Understand needs within the Market, understand and communicate innovations and technologies developed internally and their value in the market


• Develop structural tension necessary to release products and services into market, as well as to be the voice of innovation and change required within the business to deliver quality and innovative goods

• Delivery - The Business, esp. Supply Chain Management




• Develop, acquire, Deliver necessary services, supplies, and training to enhance quality of adoption

Business Process Engineering and Business Intelligence

Two buzzwords. What do they mean?

To me, BPE is all about changing the way the organization uses its resources; seeking to improve efficiency, cost, quality, and time. It generally uses IT but IT is not the only tool it uses. Other tools that BPE uses include: re-organization, training, and good internal communications and programs. This is my favorite topic, and I think the most important one for business: How are we using our resources and how can we better use them through the adoption of technology.

Business Intelligence to me seems way more vague and stupid than BPE. One way to look at BI is through the lens of Six Sigma: Define, Measure, Analyze, Improve, Control. I think that BI is about Defining systems that create Measurements and then Analyzing what's going on in the hopes that the system can be Improved and Controlled. BI gets into designing measurable systems so they can be controlled. That's all.

The Ideal Enterprise

What does the "ideal" enterprise look like and how does it behave? A few components:

1. Role-based everything - The organization knows what Jobs it has and what roles are played in its processes.
   
2. Process Management - The organization knows what its key high-level processes are and how they interact. This is essential for control.
   
3. Project Management Office - The organization knows what projects it is currently working on, their status, and the tools they're using. This helps manage change and progress.
   
4. Tools known, supported, and described - The tools (IT systems) that the organization uses are known and their uses transparent. There are sufficient resources to support them, add new users to them (training), and improve them.

Having all of these things helps the organization control and improve itself.

Making Companies is like Making Movies

There's a lot to be learned from Hollywood for the production of software. Making software isn't (or shouldn't be) all that different from making films. Since the early 1900's, Hollywood has been pumping out film after film. Technologies have of course changed over the years but the end product of a motion picture remains. Software is similar. Hollywood's "simple" process of pre-production, production, and post-production is a powerful tool. And its simple roles of Scriptwriter, Producer, Director, Actors, and Post-Product workers are powerful if applied to software projects.

PRE-PRODUCTION ROLES:
Scriptwriters
In film, these are the story tellers.
In software, these are also the storytellers. Their titles, however, are Business Analyst, Product Manager, Requirements Engineer, or Process Engineer.

Producers
In film, these are the guys that get the money and form the team.
In software, these are the Project and Program Managers (or above) who get the money (from investors or internal sponsors) and form the team.

PRODUCTION ROLES:

Director
In film, the director is responsible for the creative work and directing the actors.
In software, the IT Project or Program Manager does the same thing. The actors in software are the designers and developers who are creating the end product for the customer.

PHASES:
Pre-Production
In film, this is creating and refining the script, getting the actors, having a plan, and budget.
In software, this is creating and defining the software, getting the developers, having a plan and budget.

Production
In film, this is "shooting" the film and having the actors act according to the (sometimes changing) plan.
In software, this is "coding" the software and having the developers code according to the (sometimes changing) plan.

Post-Production
In film, this is the work involved in creating the final product of sufficient quality.
In software, this is QA work and is generally iterative where things are returned to developers to fix.

Iteration
In film, iteration is common. Many "takes" happen.
In software, iteration is common. Much "rework" happens.

So in total, I hope you can see that a patter and relationship emerges between film and software. They're the same. They're both productive processes generating a product for an audience. Applying more of our knowledge of the film industry and how it works to software would improve development lifecycles, decrease budgets, and improve user-satisfaction.