One many, many one

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

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

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

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

How low will you go?

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

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

The sexy parts of project management

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

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

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

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

Make the budget last

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

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

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

Plan, Present, Collect, Transform

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

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

Presenting is showing the users data.

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

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

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

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

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

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

What are your experiences with this?

Workflow foundation: new capture. SSIS: existing capture

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

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

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

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

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

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

The two faces of business intelligence

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

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

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

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

How much do you care about how the product LOOKS?

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

The project database that you want

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

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

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

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

The projects should also list:

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

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

Let's get this started today.

Store and share more project metadata

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

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

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

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

Give your customers a new language

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

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

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

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

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