Startup Teams with HP on Cloud-Based Testing
Published by Brad Egeland | July 3, 2009 | Leave a Comment
I received my latest copy of InformationWeek recently and found this article interesting – especially since all discussions these days seem to center on either Cloud Computing or Agile Development.
Skytap is a startup that tabs themselves as the leading provider of cloud-based virtual labs that deliver 100% self-service provisioning of complex IT environments without any architectural changes. Cloud computing is poised to become the defining technology of the 21st century and Skytap’s goal is to make serving up virtual machines over the internet as ubiquitous as delivering html to a browser. They are working to maximize efficiencies, minimize costs, eliminate unnecessary hardware, outsourcing, eco-efficient computing, and doing more with less.
I’ve worked many very large-scale government contracts where testing was a massive onsite effort involving additional hardware, software, and bodies in a compressed and stressful timeframe. Cloud-based testing would have made those experiences much more sane. And it was solely my responsibility at the time to make those tests happen and help ensure their success.
Likewise, my time in the gaming industry involved load testing for slot data management software. It’s necessary to test slot machines against large loads of usage – the last thing a very large casino gaming entity wants to happen is for their slot system to crash on a Saturday night due to heavy customer usage!
Without further ado, here is the article written by Charles Babcock for InformationWeek…
“Startup Skytap has cut a couple of powerful alliances for it’s cloud computing services, most recently joining forces with Hewlett-Packard to make it easier for companies to stress-test software against thousands of simulated end users without taxing their won data centers.
Skytap – named one of the InformationWeek Startup 50 in April, shortly after getting $7 million in venture funding – offers a Virtual Lab where developers try out applications by building test environments from its library of operating systems, databases, and middleware. Skytap already partners with Microsoft to enable Visual Studio Team System testing.
Skytap is providing HP’s LoadRunner testing tool to build test scenarios that push an application’s limits. The tests can be set up, managed, and torn down through HP’s Quality Center, which uses Skytap’s cloud computing resources to execute the actual test. The tests run as virtual workloads under VMware’s ESX Server.
Cloud computing is seen as a lower-cost way to offload workload spikes from the data center, and testing and quality assurance are likely prospects. Other cloud computing services such as Amazon Elastic Compute Cloud also can be used for testing. Companies pay Skytap from $1,000 to $10,000 a month for cloud-based testing.”
A Quick Guide to Performing a Vendor Market Analysis for Your Large Project
Published by Brad Egeland | July 2, 2009 | Leave a Comment
This is basically a “Quick Guide” version of the 5 part piece I wrote on “Performing a Market Analysis for your Sotware Project Solution.” In this scenario we assume your company needs a project handled and it’s going to require that an outside company has a hand in it and it’s important that you get the best because it’s going to be long and it’s going to be costly. It’s important to analyze the available options and make the right choice.
I’ve broken down the detailed market analysis into the 7 separate phases detailed below. For the full detail, start with Part 1 and read through all five articles covering the 7 phases in greater detail.
Phase 1 – Document the Requirements
It’s critical that you and your organization have detailed knowledge of your requirements and business processes going into a market analysis like this.
You need to know what your requirements are, what your ‘as-is’ business processes are and what you want your ‘to-be’ business processes…um…well, to be. If you don’t know that, then you’re not ready for this and you’re certainly not ready to move on to Phase 2.
Phase 2 – Identify the Potential Sources
Initially, you and your team need to identify who the main players are. Know which vendors you need to initially consider for this undertaking. Make the field too small and you won’t get a good cross-section of the offerings and capabilities. Make the field too large and you will spend too much time and money just narrowing the group down to the size it should have been in the first place.
Phase 3 – Vendor Initiation
Let’s assume you start with 8-10 vendors who are offering a software package or implementation that, at least on paper, comes close to what you visualize your end solution to be. In your gut you know that 3-4 of them probably won’t cut it, but they’re worth a closer look. Include those 3-4 ‘on-the-bubble’ vendors and let them play themselves out of consideration because one could surprise you and offer a reasonable solution at the best price.
To start things off, contact each of the vendors via email with the following information:
- An introduction of yourself including your contact information
- A summary of your project or software need
- An invitation to participate in the market analysis
- A proposed date/time for a one-on-one kickoff call
Phase 4 – Vendor Research – Round 1
You can’t run the whole market analysis with 8-10 potential vendors. Well, you can, but it will be too lengthy and expensive. It makes more sense to break it into 2-3 rounds and eliminate some vendors along the way. At the conclusion of Round 1, I’d recommend trimming it by 3-4 vendors down to a maximum of 4-6 offerings.
For Phase 4:
- Send out a high-level questionnaire with some qualifying show-stopper questions (10-20 must-haves) on how the vendor meets the qualification
- Review/score the questionnaires as a team
- Remove 3-4 vendors from consideration based on the scoring
- Notify vendors being removed from the process and invite the remaining vendors to continue with the market research
Phase 5 – More Detailed Vendor Research – Round 2
For Phase 5:
- Contact the remaining 4-6 vendors via email and/or phone to invite them to continue with the market analysis and explain what is intended for this phase
- Provide a more detailed list of 20-40 requirements for the vendors to use in the round 2 demos – give them 1-2 weeks to prepare a demo that discusses their capabilities against those requirements (set these demos up as remote webex demos – face-to-face meetings are not necessary yet
- Following each demo gather as a team and discuss their pros and cons and conduct some sort of scoring for each vendor against your list of requirements
- Contact the 2-3 vendors that are being removed from contention
- Contact the 2-3 vendors that are moving on to the final round of consideration
Phase 6 – Final Vendor Demos
In Phase 6, you will need to perform the following:
- Provide the vendors with a lengthy list of even more detailed requirements
- Setup detailed face-to-face vendor demos either onsite at the customer location (that’s you) or at a centralized location (really only necessary if you have a dispersed team)
- Request and receive project cost estimates from each vendor covering software costs, maintenance agreements and implementation costs (these are not expected to be final, binding cost estimates…just ballparks for scoring consideration)
- Meet as a team following each detailed vendor demo to perform scoring, compare notes, make preliminary decisions about the vendor
Phase 7 – Final Scoring and Selection
This phase will involve a final team review of the materials, demo notes and preliminary scoring, performance of joint scoring, determination of the finalist, and notification to the losers and the winner.
Be considerate with the notification to the runner-ups because they could be called in to fix a failed implementation should the chosen vendor not be able to perform. Remember, they’ve gone through a lengthy and costly process to get this far.
Now it is time to sit down with the chosen vendor and do the following:
- Negotiate a final price
- Provide an official Statement of Work
- Provide final requirements
- Define a draft project schedule
- Identify key milestones and deliverables
- Establish project team roles and members on both sides of the project
- Schedule a project kickoff
Summary
You’ve successfully completed a lengthy process to identify the best and final solution to your software need. Monitor the process closely early on so a switch in vendors can be made, if necessary, with minimal impact – both cost and timeline – to your company. However, move forward with confidence because at this point a considerable amount of effort has been expended by your SMEs to identify the best solution and you’ve found it.
What to Do When There’s Nothing to Do
Published by Brad Egeland | June 30, 2009 | Leave a Comment
Whether or not you’re ever in this situation probably depends a lot on the size of your own personal project portfolio and how your company handles projects. It’s happened to me a few times, but it’s not a constant.
Here’s the scenario I’m talking about…. You have a lot of projects on your plate. For me, when it happened the most is when I had maybe 12-15 projects on my radar at any given time. 4-5 of those projects would be very active – moving ahead full steam. Another 4-5 of those projects would be moving along slowly – possibly experiencing some sort of delay but moving along never-the-less. And then there would be a final list of 4-5 projects that seemed dead in the water but promising to jumpstart as soon as one of the following happens:
- Customer funding kicks in
- Customer agrees with the price or estimate (depending on whether it’s an external or internal project)
- The right internal delivery resource becomes available (really only applies to internal projects – you can’t hold an external customer up for an internal resource…you’ll be out of business)
- The customer is waiting on the right customer-side resources to staff the project
- Did I already mention funding? (the most common reason a project – especially internal – would get stalled to the point of death or near death)
For the purpose of this article, I want to look at those 8-10 projects that aren’t moving along – or are moving along at such a slow pace they’re like the rotating bar atop the Peachtree Plaza in Atlanta – you’re trying to figure out which part is actually moving but you can’t because it’s all moving too slow. Ok, maybe I had consumed one too many drinks and I was sitting with the future runner-up to Miss America, but it was a long time ago and I was in college.
Staying on Top of Things
So how can we keep track of those nearly dead or slow moving projects? Well, we don’t need to keep track of them so much as we just need to stay in touch with them. It’s easy to let them fall away because we’re swamped trying to ensure the success of the 4-5 projects that are hot. But we can’t overlook these other projects. They still need care and feeding…the customers still need us to reach out to them – they need to know we’re still in the game and ready to kick things off again when they’re ready or when whatever is holding things up is lifted.
Here’s a few ways we can make sure we’re still in sync with our customers and our teams for each these stalled projects project:
- Maintain weekly contact with the customer – no status reports, but a call or quick face-to-face (depending on logistics) to share any updates, etc.
- Weekly communication with delivery team resources assigned to your ‘on hold’ projects to provide any updates, ensure they’re still ready and available if and when the project starts up again
- Regular communication with your delivery team resources’ direct managers to keep them up-to-date on status – if your currently assigned resources are going to be assigned elsewhere, then you need to know you can get skilled replacements fast if things start up quickly and the only way to do that is to keep managers informed
- Regular updates to the PMO Director (if applicable) so they are aware of the status of each stalled project and can make adjustments to your work project assignments accordingly
Summary
In reality, there’s usually little you can do for a project that is stalled or on what seems like permanent hold. What you can do as the Project Manager in charge is maintain regular contact with the customer or project sponsor to let them know you’re still out there, ready and waiting. Sometimes that will help jar a project loose to get it started again, but it will also keep you in front of the customer when the current stalled project restarts and hopefully will move more engagements from that customer your way.
Project Management: The Art of Keeping it Real
Published by Brad Egeland | June 30, 2009 | 1 Comment
The Formal Stuff
We do a lot of ‘formal’ things on the projects we manage. Hopefully, if we’re good project managers following a reliable ‘process’, then we hold meetings, deliver status reports, track issues and risks, forecast resources and costs and have a detailed project plan up-to-date every week if not every day.
We can formally project manage our butts off and still not have a successful project. Sometimes there’s nothing that can be done about that. Things go wrong, technology fails us, team members let the project down, executive management cans a project, or even the customer changes their direction and it just doesn’t meet their needs anymore.
However, there are times when things that make a project unsuccessful are very much within our control. If we’re not managing the project well, that can be one of those instances in our control. But I’m writing this with assumption that we are doing the right ‘formal’ things on the project as stated in the first paragraph above. What I’m talking about here is the little things. The things that make or break customer satisfaction, team satisfaction, and even CEO satisfaction and help ensure our project’s success – or kill it.
The Extra Effort
Some of the things we can do – the more intrinsic things on a project that keep people happy, involved and focused are:
- Frequent communication with the customer well beyond the required weekly formal calls and reporting
- Understanding customer concerns and offering expert advice and possibly additional skilled project resources to address questions and concerns
- Frequent adhoc discussions with our delivery team as a whole to keep everyone focused and engaged and make sure where all aware of the key tasks and assignments at any given time
- Frequent adhoc discussions individually with our delivery team members to dive into any project, professional or even personal concerns or frustrations they are encountering (don’t let anything build up – it’s never a good thing)
- Especially for very visible, large projects – frequent communication with and updates to executive management
- Invite the CEO or other executive management to sit in on a weekly customer status call – it will inform them, make the customer know just how important they are, and let your team know how valuable this project is and how important they are to it’s success
Summary
There’s more we can do, I’m sure. The key thing to take away from this is that just following formal processes is not always enough. It usually isn’t enough – especially on larger and longer engagements where team members can stray, become exhausted or unfocused, feel unappreciated, or the customer can feel like they are being taken for granted. You’re the Project Manager – keeping everyone engaged and satisfied is not easy, but it’s your responsibility and ultimately increases your chances for success.
We Learn from What We Screw Up
Published by Brad Egeland | June 29, 2009 | 3 Comments
The title basically says it all. We go to school, we go to training classes, we join associations, we read books. We do everything good little IT and business people should do to better ourselves in our profession. And, at the end of the day, we’ve learned some things that help us in our jobs.
But what do we really learn the most from? Growing up, did you learn more from what you were told to do or did you learn more from what you did wrong and had to pay the consequences for? I contend that the latter wins hands-down. It’s nice to learn things…it always is. But when we screw up really good and pay some sort of price for it…I contend that those are the times that we really really LEARN.
Example #1
Case in point…. I’ve mentioned many times how budgeting issues can torpedo projects and I’ve had at least one major project of mine go south due to budget handling issues. I’ve passed blame somewhat, but overall I’m the Project Manager and that’s my responsibility. That which does not kill us makes us stronger, right? I firmly believe that. And that which does not get us fired makes us a better employee, a better server of our customer, a better business professional.
One major project completely shutdown for budget issues that could have been avoided – or least the blow could have been softened – with the appropriate action. I learned from that mistake and budget information is key to weekly discussions and project status reports that I have with and share with the customer now. It’s formally documented – both current budget and forecasted budget – and discussed formally every week. I’ve taken away the question marks and made it a joint effort with the customer. And believe me, the customer always appreciates the knowledge and would rather know the bad things and work through them with you then to waste money and cancel an engagement. I’m certain of that.
Example #2
I also worked on a major $50 million program for the US Department of Education. It was much more of a program than a project – it had a five-year run followed by an RFP process and our proposal and another contract win. The company I worked for always won it because the program had grown to such a large size, it was so complex and had so many add-ons that no potential bidder could knock us – the incumbent – out of contention for the next proposal. We had become fat and overconfident.
Then one day a funny thing happened. We missed a major milestone deliverable. Then we missed another. Then we improperly tested a change order resulting in delays and re-work. Suddenly, the government was not so enamored with our performance and certainly had lost confidence in our ability to deliver. We desperately needed to learn from this mistake, act aggressively and right the ship before it was too late – because at this point the project was within one year of coming up for re-bid.
I had responsibility on this program for all financials and budgeting, all change management, all change orders, disaster recovery, and status reporting. Production was not in my scope, but I pulled my direct reports together and we resurrected the project schedule that I had put together 3 years prior in order to win the current contract and we updated it to what was happening today. What my team and I turned out was a project schedule encompassing nearly 4,000 tasks and a my peer managers on the program were ready, willing and equipped to manage their specific portions of this mammoth project schedule.
My responsibility was to bring that all together and take over leading the weekly status meetings with the government managing everything to that schedule and producing meaningful alert reports from it both for internal purposes and for the customer to hold us accountable to. What resulted was a project that quickly got back on track, a customer whose satisfaction was raised beyond the level it had been previously and another huge contract win down the road. It wasn’t my doing – my entire team and I took the initial action – but everyone pulled together and made it work. We learned from our overconfidence and mistakes before it was too late. And in this case too late could have meant losing our jobs in a year if the contract was lost.
Summary
We’re human…we’re told what to do from the time we’re born till the time we die from someone or another. It doesn’t matter if we’re John Doe or Donald Trump…someone somewhere is instructing us off and on. We learn from those instructions. But I believe we also learn very fast – maybe faster – when we screw up and suffer the consequences. Sometimes we have to fail to perform better.













