Agile is an incredible methodology for running IT projects. However, at times you are asked to come up with a swag as to how much money and resources it will take to complete a project. Modeling the complexities of resource requirements, time and expense can be difficult. I recently put together a spreadsheet to assist in this activity. I had every intention of moving this to an online application, but do to time constraints I have not had the time. So I’ve decided to release this tool in, gasp!, Excel. Please feel free to use as is, but if you beat me to creating an online tool at least put a link back to my blog!

First, a quick explanation of how the tool works:

Only edit the light blue fields

Story Points Total – Total story points the team estimated for the entire project

Time Frame (Months) – Sometimes the business expects that a project needs to be completed in a timeframe. This cell allows you to calculate that. The warning here is that you need to be realistic. 9 pregnant women can’t have a baby in a month. If you don’t understand that statement than you need to cease and assist the use of this tool immediately! Advice: Just be realistic.

Blended Resource Rate – The blended rate of all available or projected resources.

Contingency – This is a swag. Enter a % of ‘play money’ to each side.

Story points conversion – Agile purists hate this. But in some situations you have to convert a story point into an hour estimation. This field allows you to estimate time to quote. More importantly it allows you to model scenarios.

Headcount – The Dev line item is automatically calculated. Remember, you are trying to back into the number of developers you’ll need and the amount of money you will need to complete the project. Developers are the big unknown. Other resources are fixed or can be calculated as a ratio (i.e. One QA professional per 3 Dev’s). Again, this also allows you to model resources needed to manage the number of dev’s you are calculating. Add your PM’s, Scrum Masters, QA people here.

Capital Hardware – It costs money to run this new stuff. Add your costs here.

The three columns related to cost and number of resources models out the amount of dedicated resources. Dedication is an estimate. Your resources will go to meetings, use the bathroom, etc. One thing I will guarantee you, they will not be productive 100% of the time. I’ve found that the team is productive between 80 and 70% of the time allocated. Use these columns to provide a range.

This is where the TSA and IT Governance have something in common. John Tyner set off a national outcry regarding the use of some of these techniques designed to keep us safe. There is no doubt that ‘Naked Machines’ and intrusive pat downs will keep the flying public safer than not having them. But at what price? Personal privacy, longer lines, inconvenience, etc.. At some point someone was going to have an issue and set off a fire storm. The end result, in my opinion, will be an extensive review about the effectiveness of these searches and political pandering that will end up reducing the ability of the TSA to keep airline passengers safe. One sure thing is that the TSA will suffer a reduction in public trust and ultimate legitimacy as a public safety entity. Move over IRS and The Post Office, there is now someone more hated.

Unfortunately I’ve seen these same types of events (although everyone was clothed) happen in our industry. IT Governance and PMO organizations have a tendency to think that adding more process or rules is a good thing. After all, they initially improved processes in the past. However, there is a tipping point where the implementation of more rules ultimately ends to less impact. Ultimately becoming detrimental to the very SDLC process you seek to improve. Then, everyone starts to question the effectiveness of the PMO or IT Governance. Essentially leading to IT Organizations have their own John Tyner moment! The result is the same. Good intentions end up having the opposite effect of which they were intended.

My advice to IT Governance and PMO organizations is to constantly reevaluate all your polices. A mature development organization should, in most cases, have less policies and procedures in place than one just starting out. You need to constantly evaluate your maturity level as an organization and make adjustments. Prejudice should be placed on removing roadblocks, not creating them. Don’t turn your development staff into a bunch of John Tyner’s.

I’m sitting here on a Friday night doing what all geeks do. Reviewing blogs and of course catching up on Dzone.com! I was checking out the top links section when I came across Jared Richardson’s recent post ‘You’re a Bad Manager, Embrace It’. I have to admit I’m a little shocked at his article as a sort of bitter commentary on the state of IT management. I’m the first one to tell you that the future of IT management concerns me as well but as someone who does manage development teams I would like to provide some insight.

First some things I truly believe as a manager:

Developers are professionals, treat them as such. They didn’t get to where they are because they are incompetent. If you hired right, they are better than you ever were as a developer.

The team is everything. You fail as a team and you succeed as a team.

Promote your teams, always. Your job as a development manager is to maximize your teams opportunities. This is distinctly not a team sport. If you fail at this the blame is solely yours.

Protect the team. Distractions like office politics, budget fights and general obstacles keep the team from doing what they do best: be development professionals. Your job is to clear the field so the team can perform to the best of their abilities.

The funny thing in reading Richardson’s post is that I can see where some of these frustrations come from. However, I’ve worked with very few inept development managers. Perhaps I’m just lucky but I think as someone who has spent some time in management I can see both sides of the coin. Let’s start by examining some of his thoughts:

“When your team gives you an estimate for how long they think work will take, you always reduce it. By dropping 25 to 50 percent of the time, you like to think you're pushing your team to do their best. We all work better under a deadline, right?”

Estimates are just what they are. Estimates. We all play this game everyday. Whether buying a car, getting work done on the house or even doing a personal financial budget. Management wants something. We, as in the team, want the appropriate amount of time and money to do something the way we want it done. Your job as a development manager is to translate for both sides. Simply slashing time or taking an estimate at face value is wrong in either case. If you have no negotiation skills than perhaps management is not for you.

Perhaps the most annoying, and perhaps dangerous, argument is the one that Richardson makes next (I’ve heard it at least a dozen times):

A typical developer, after you factor in benefits and the overall cost of employment, costs you from 150,000 to 200,000 dollars a year. If you have a ten person team, you can buy them extremely high end workstations for around $3,000 each. That's $30,000 a year to save two man years. Does that sound like a good investment?

I agree with this but there is a hard reality that every developer (and management hopeful) should know. I would like to set a scene for everyone reading this. You as a development manager go to the CIO or CFO and explain this great opportunity to increase productivity. The CIO or CFO have read the latest article in CXX magazine about the benefits of offshoring. They won’t even get to the saving of two man years. They will just see the $150,000 to $200,000 cost. Personal experience tells me that you don’t want to spend the 100+ hours of power point presentations justifying the value of your locally based team. Trust me on this. There are better ways to get the equipment you need. You just need the ability to translate the need without exposing the team to risk.

Now something about rewarding the team:

Speaking of rewards, like most bad managers you reward your developers individually. You provide bonuses and raises to the top performers, and less for the middle, and none for the "low performers". Then you stand back and wonder why they don't perform as a team. Why they refuse to help each other and compete with each other.

This gets back to the culture. The team is everything. Perhaps I should have made this # 1 on my list. Great development teams self organize. Developers know who are top performers and who are not. This does not mean that you only reward the most experienced. You reward the top performers at every level, entry level, mid’s and sr’s. I have yet to manage a team where the top performers allow the ‘low performers’ to bring the team down. They always pick up the ‘slack’. Your job as a manger is to know who the top folks are and get their input. No top performer wants to work with someone not pulling the team forward. It’s a team effort. Drop the weight of low performers and increase team moral by demonstrating that your more than willing to cater to the self organizing and self managing team’s wishes. They are after all, the best suited professionals to make that determination.

I’m by no means saying that Jared Richardson’s article has no merit. I’ve heard plenty of management horror stories. Bad managers are out there. I respect his attempt to shine some light on what it takes to build great teams and look forward to more of his posts!.

I am going out on a limb here. Technologist are not traditionally people persons. Please insert your own Office Space quote [here]. Technology is a profession I love. Make no mistake. But, we have our issues. The issues have nothing about capability or effectiveness. We are very good at that providing solutions to problems. Our problem is self promotion!

When thinking of traditional Technical Evangelists I believe most people picture someone that promotes a platform or a proprietary service such as the ones Microsoft and SUN have employed. Currently, I believe that Steve Jobs is the best known evangelist given Apple’s recent product home runs. However, I do believe there is an opportunity for smaller shops, or even your own company, to employ the same strategies to maximize technology value to customers.

I think at face value this makes sense, but just for fun let’s examine some everyday scenarios that support an evangelist position:

The pace of innovation is increasing. You need to be agile in your evaluation of new technologies and how your business can leverage them to deliver a step change competitive advantage.

Your leadership team probably interacts less with technology less than your IT team does. You need to continually bring new opportunities to the forefront at every chance. Perhaps an evangelist should even be present during board meetings? Can you imagine; IT being a strategic business partner??? I kid of course. It’s what we should be!!!

Your customers are becoming more tech savvy. There are no more secrets in Technology. They have access to the same vendors and solutions that everyone else does. You need to put someone in front of them that can inspire them. Leave the sales transaction up to the sales team, build interest and excitement for the product up to the evangelist.

Building a product and selling it is just 30% of a launch (my take on it). You need someone to continually look for ways to promote the product on a micro-interaction level. Be it whitepapers, speaking at local groups or even through blogging and social network sites.

Customers need to be ‘connected’ to the product to build loyalty and honest feedback. Nothing makes your IT product more replaceable than a customer feeling like they have no feedback loop or someone they can identify with. Did you notice the recent Microsoft commercials about ‘Windows being my idea’?

So how do you position the need for a product evangelist? Moreover, how do you convince the ‘brass’ that one is needed? My current employer does not formally recognize the role, however I believe that each leader in the IT organization informally plays the role. I think a large part of that is due to the fact that our IT department is viewed as a strategic partner in business decisions and efforts. For many organizations that’s a tough road to pave. I’m admittedly lucky.

Those of you seeking to build a case for implementing an evangelist culture I would work to tie the five points above with specific plans or actions to address them. Building legitimacy is key. Challenge your current status quo by continuously providing competitive analysis and how you can overcome those challenges by bringing forth new technological advancements. It’s a small step and the culture will not change overnight. However, it’s a step in the right direction. Remember, overnight success usually takes 3-7 years. Even for Google!

I would be happy to read and repost any stories on how you successfully implemented an evangelist role or culture. I think this is an important component of IT’s growth and I’m happy to share.

I’ve been busy attending some conferences lately where I’ve had the chance to speak with IT pros across several industries. What I found most interesting is that even amongst this diverse group there seems to be some common themes of interest and focus. Sure, we spoke about cloud computing and virtualization, but at a higher level there were two underlying drivers to their strategies.

There are no longer any secrets in Technology.

Know the true value of IT.

There are no longer any secrets in Technology

This statement sounds odd at first. However, when you really think about it there are none. Your competitors have access to the same vendors and technology that you do. How they effectively put them together might be a secret, but at the end of the day the access is the same.

So what can you do to compete? Speed. How fast can you deliver to the market? To put the pace of technology in prospective please play the video below:

The video is a few years old, but you get the trend. Speed is of the essence. So what do you need to do to be in a position to out ‘speed’ your competition? Simplify your processes and your architecture. These are perhaps two of the most taxing aspects of software development. If you are not concentrating on streamlining these you’re probably not going to out flank the next ‘startup’ looking to capture your customer base.

Know the true value of IT

This one probably hits home to most IT folks who work in corporations. You need to constantly justify your existence because someone will inevitably ask; What value does IT provide? I think as a profession we commonly whip out ROI calculations on the projects we’ve completed or SLA’s that demonstrate our ability to meet some number that the business could ultimately care less about (show them that you have a 4 hour window when email goes out and see the reaction). I hate to break it to you. Meeting SLA’s and calculating ROI’s is not IT’s value prop.

IT’s value to the business is as an exponential transformational force that underpins all business activities. It sounds a bit ‘Star Wars’, but let me prove it to you.

If you’re one of the fortunate souls that regularly has to calculate ROI’s for proposed projects you need to ask yourself the following question. Three years from now will they come back and check to see if the ROI is realized? If so who gets fired if it’s not? I venture to guess that the answer for 99% of people is no, and no one. Need more? Have you ever calculated that a new piece of software will automate X number of headcount? When have you ever seen that headcount reduced or reassigned after delivery? No, they just get to do more of the same thing, just more efficiently!

What you need to be looking at is how can you dramatically transform a market or a business process to give your company a competitive edge! It sounds dramatic, but it’s really very simple. For example: Why make the ‘order’ entry simpler so people can do more of it? Why not focus on automation so you can reduce headcount and improve accuracy?

I know what your thinking. That should go into the ROI calculation for sure. And you are correct. However that is often what I see go wrong. Too many times business leaders ask to make something simpler or ‘shinier’. Our value as IT professionals is helping them realize exponential transformations by pointing out opportunities that they might not even think of. That is the true value of IT!

Anyone who writes code is always interested in the capacity (or load) that their system can handle. For some, including this author, it’s a matter of pride and bragging rights. However, there is a different type of capacity that is normally overlooked. When was the last time you estimated your team capacity?

Your team capacity is as equally as important as system capacity. Team capacity determines how much work you’re getting done and, at the end of the day, how much value you’re giving to your customers. I think that most folks automatically assume that their team capacity is some magical number calculated based on the number of people that work on the team multiplied by a ‘hours per week’ number. Although this isn’t entirely incorrect you might be short changing yourself.

So to start, let’s talk about what factors go into team capacity planning. There’s the obvious, availability of the team. You can’t factor forty hours a week if your team is also dedicated to other tasks. What about complexity of the tasks? There are methodologies out there that can help you plan for that. What’s missing from the equation? Simple, budget, talent and infrastructure. Let’s take a brief dive shall we?

Budget

Most projects have budget constraints. However, you need to weigh your available budget with time. I think most people think that if you have 5 FTE’s (Full-time employees) working for six months on a project and it takes up the entire budget you’re probably doing better than most. What if you have 2 FTE’s and 3 contractors that complete the work in 4 months but still fit within your budget? What about 2 FTE’s and 3 contractors and it still takes six months? Is it worth it? Now you have freed up 3 additional FTE’s! You now have just added to your team capacity. You actually end up retaining intellectual property because of your FTE’s, but get the work completed by augmentation. The pitfall is that typically a contractor will always cost you more. So you need to figure out what the difference is between time and cost in order to take advantage.

Infrastructure

Infrastructure is the key to making budget and talent work. When I talk about infrastructure I’m talking about your team’s ability to ramp up an outside resource. You need to ask questions like: How long does it take to setup our environment? How long does it take for them to understand our architecture? What software will they need to complete the work? I’ve seen a lot of talent and budget wasted on this over the years. If you want to increase team capacity you should focus on the ramp up. And not just for augmentation, but for your own team as well. Either way a solid infrastructure adds to your team capacity.

Talent

Talent is probably the most important aspect when considering team capacity. I’ve spoken about budget and infrastructure. However, if you don’t have the talent to manage ‘additional capacity’ then you might as well have stopped at paragraph one. If you follow budget and infrastructure than you need someone to help you manage the additional ‘capacity’. This is where you need to invest in the team. Based on my experience, a good senior level technical person can manage three to four staff augmentations (read contractors). Again, the benefit is that you keep the intellectual knowledge in-house, but increase capacity at the same time.

Conclusion

So what is your true team capacity? By factoring in talent, budget and infrastructure you can dramatically raise your team’s ability to meet your goals.

I was having a discussion the other day about the fact that I often times come across as hopelessly optimistic at work. Specifically the conversation centered around some recent work and project challenges my team was facing. Members of my team felt that despite the outlook I always seem to have a misplaced positive attitude. This lead to a great deal ribbing and a bunch of ‘the man’ jokes. Make no mistake, I offer no apologies and feel that it’s an important trait of any leader no matter the occupation. I think more should adopt the trait.

First, a little background on the title. I was speaking to my wife about the exchange and explained my take on my perceived constant optimism. After a long conversation she smiled and said you’re ‘anti-anti Pollyanna’. For those of you that are not familiar with the novel (I had to look it up too) the book is about a girl named Pollyanna who plays what is known as ‘The Glad Game’. Essentially she finds the good in everything.

So why am I the ‘anti-anti Pollyanna’? The first is that I have 100% confidence in my team to tackle any challenge. They are, in my world, the best at what they do. They are some of the most competent technologists I know or have ever known. It’s easy to have a positive outlook when you feel that your team can tackle just about any obstacle.

Secondly, as a manager, the people that work for you hang on to every word you say. This is not a self serving statement. People buy cars, homes, and plan for the future based on how they feel about job stability. Think about the recent interactions with your supervisor. Has anything they said made you double think your current job satisfaction or worry if there will be a pay check next week? I would be willing to bet you could think of half a dozen instances.

I think in terms of software development this is even more important. As Technology managers we have a tendency to think more about brining the current project on time and under budget than the ones we manage. People are the asset, not the project and not the software. As managers we invest significant amounts of energy, time and money to the development of great teams. Bad attitudes and bleak outlooks can significantly reduce your ROI on the talent pool you’re attempting to build.

Managing people is an awesome responsibility that I think some folks take lightly. Make no mistake, it’s what you are paid to do and just like everything else in your career you should strive to do it well.