As I have mentioned previously, Development and Maintenance are two separate things. Development is more risky and, consequently, more costly. Maintenance is less risky and should cost less. But when you make this adjustment you must consider the additional complexity involved with the system.
In my situation I have a system that was initially developed, is going into maintenance mode, but we are also working to expand the functionality into other programs. This means that I have both maintenance and development currently underway. Since I sent the maintenance work to a separate team this means I have two different sets of developers working on the code.
This introduces some risk into the process and requires some additional planning to efficiently and effectively manage the code for both of these teams. In my situation, I'm doing what I had planned, I have 4 releases programmed over the course of the year to maintain the application. But then I have the Development team working to extend the functionality to other programs and they are using an Iterative Development life cycle. Iteration 1 comes out in a couple months. That means that both the development team and the maintenance teams are working on the code at the same time.
I probably glossed over this issue in my previous posts. It is CRITICAL that you implement a really strong CM process to make sure that both teams are able to be productive and leverage work from the other team.
Monday, November 30, 2009
Tuesday, November 24, 2009
Dare to Dream, a 2-Factor Smartphone
This is the time to be thankful, and let me please start by saying how thankful I am to be clear of the RAZR and Treo I was carying around. I have nothing but love for my new phone. But...
Like most or many federal employees I have an ID card, technically known as an HSPD 12 badge. It looks just like this, only with a much more attractive picture. See that little gold thing towards the bottom? When I insert that into my laptop it sends a signal to initiate the authentication process. When I type in my pin or password it completes that process and allows me access to the LAN, network resources, the Intranet, email etc.
It is good because it is easy and secure. It is more secure than a really hard password simply because it has 2- factors, something you have and something you know. The thing you have is the card. The thing you know is the pin or password. Either of these without the other is not good enough to authenticate a user. I might lose my card, and we wouldn't want someone else going around pretending to be me. So, I have a pin, which, for me, is easy to remember, but is not likely to be guessed. The problem with this is, that the laptop I use, while really nice, is like 22" by 17" by 2" and weights, 5 pounds. It's cool for taking on a plane when I have to go on a trip, or for working at home. But when I go to a meeting and want to be able to check my email between meetings, it's kind of a pain there. It doesn't easily fit into my pocket.
But, what I do have is my new Droid. I could check email and my calendar and do lots of stuff that I would normally do on my laptop on this smartphone, and, bonus, it does easily fit into my pocket. The issue that I have is in authentication. Thus, while I have a really hard password, that is like honestly 18 characters, upper, lower, alpha, numeric and special, it is a real pain to try to type that super hard password into my new phone.
As such, I propose a marriage. Build a smartphone that includes the capability for me to insert my HSPD-12 badge into it (Factor 1) and allow me to type in my PIN (Factor 2). This would allow me to access all of the same resources I use when I'm logged into my laptop without going through GOOD. No offense to GOOD, I just don't like your software. My opinion is that Good is unproductivity software because it makes things more difficult.
So let's try to create a hardware solution to authentication. Try to focus on 2-factor and make use of stuff that most of us have anyway. Put a card reader on a smartphone and I guarantee you will command this segment of users. If you want to take it to the next level you will create an ap-store by agency that will allow USDA to identify the applications that can be installed on USDA smartphones and HHS to identify the applications that can be installed on their phones. Then, as an authenticated employee, I can cruise through that store to install the applications that I want, and we get to avoid applications that hold risk.
Like most or many federal employees I have an ID card, technically known as an HSPD 12 badge. It looks just like this, only with a much more attractive picture. See that little gold thing towards the bottom? When I insert that into my laptop it sends a signal to initiate the authentication process. When I type in my pin or password it completes that process and allows me access to the LAN, network resources, the Intranet, email etc.
It is good because it is easy and secure. It is more secure than a really hard password simply because it has 2- factors, something you have and something you know. The thing you have is the card. The thing you know is the pin or password. Either of these without the other is not good enough to authenticate a user. I might lose my card, and we wouldn't want someone else going around pretending to be me. So, I have a pin, which, for me, is easy to remember, but is not likely to be guessed. The problem with this is, that the laptop I use, while really nice, is like 22" by 17" by 2" and weights, 5 pounds. It's cool for taking on a plane when I have to go on a trip, or for working at home. But when I go to a meeting and want to be able to check my email between meetings, it's kind of a pain there. It doesn't easily fit into my pocket.
But, what I do have is my new Droid. I could check email and my calendar and do lots of stuff that I would normally do on my laptop on this smartphone, and, bonus, it does easily fit into my pocket. The issue that I have is in authentication. Thus, while I have a really hard password, that is like honestly 18 characters, upper, lower, alpha, numeric and special, it is a real pain to try to type that super hard password into my new phone.
As such, I propose a marriage. Build a smartphone that includes the capability for me to insert my HSPD-12 badge into it (Factor 1) and allow me to type in my PIN (Factor 2). This would allow me to access all of the same resources I use when I'm logged into my laptop without going through GOOD. No offense to GOOD, I just don't like your software. My opinion is that Good is unproductivity software because it makes things more difficult.
So let's try to create a hardware solution to authentication. Try to focus on 2-factor and make use of stuff that most of us have anyway. Put a card reader on a smartphone and I guarantee you will command this segment of users. If you want to take it to the next level you will create an ap-store by agency that will allow USDA to identify the applications that can be installed on USDA smartphones and HHS to identify the applications that can be installed on their phones. Then, as an authenticated employee, I can cruise through that store to install the applications that I want, and we get to avoid applications that hold risk.
Monday, November 23, 2009
Droid
Those who know me know that I have been patiently waiting for some cool phone from Verizon (maybe not so patiently). I have been using my Motorola RAZR for too long. I remember buying this phone prior to one of my kids being born and my youngest is more than 3 years old, so this phone was old. But it was a trick phone. I have had it so long that the battery has swelled up and doesn't fit the case any more. Whenever I took out the phone, the back would fall off, so it had commedic appeal. The time the back fell off into a bowl of chile was the kicker (I still ate the chile).
Anyway, I was kind of hoping Verizon would deliver an Iphone. Instead they came out with the Droid. It is a good product and I am happy with it. The Droid, manufactured by Motorola, needs to be a hit for both Motorola and Verizon. Motorola needs it for the phone division to remain solvent and competitive in this space. The Droid needs to be a hit for Verizon to stem the tide of defectors going to AT&T and the Iphone. As such the need for this combination to be successful for both companies is very high, and I think they do have a hit here.
The phone for voice calls (the reason for having a phone) is very good. I think it is better than my old RAZR and infinitely better than my old Treo. Reading email is good and the interface is sleek and easy to use. The only issue there is that the service we use for work doesn't allow me to open attachements, but they are still there. I imagine that Good will fix that in the near futurte. The operating system, Google's Android, is really cool. This is my first exposure to that OS. Obviously everyone is familiar with Apple's mobile OS (since I have an Ipod Touch), and this is consistent but different.
The big takeaway I have is that it is super fast. I mean, even maps, using my current location, so nothing that is pre-cached, is really fast. If this was baseball I would administer a drug test and expect to find steroids here it is so fast. But since it is a phone I doubt I'm going to find needle marks anywhere.
The thing I didn't realize is that the different elements can really drain the power. Which is why I have added a new blog to the list of blogs I'm tracking on the right side of this page. You'll see the Tech Broiler blog from Jason Perlow. He is starting a new section called Stupid Droid tricks to teach dummys like me how to efficiently use this device. I did have a problem. My battery drained in like 4 hours. I didn't realize that when every single service is running the machine is draining power. I read Stupid Droid Trick #1 and figured out how to easily turn off services that I don't need like disabling Wi-Fi when I'm not at home. Duh. I'll be looking for more stupid Droid tricks in the future.
Anyway, since I'm a federal employee, and we have to use the Networx contract, my department has had a relationship with Verizon and those are the only services and phones we are allowed to use. Sorry other companies, that is just how it is. So we are piloting the Droid and I really like it. I think this will really work for us. As a pilot tester it is my job to find out these little problems and identify solutions so that if we want to roll it out to the larger community they won't be forced to deal with headaches.
Anyway, I was kind of hoping Verizon would deliver an Iphone. Instead they came out with the Droid. It is a good product and I am happy with it. The Droid, manufactured by Motorola, needs to be a hit for both Motorola and Verizon. Motorola needs it for the phone division to remain solvent and competitive in this space. The Droid needs to be a hit for Verizon to stem the tide of defectors going to AT&T and the Iphone. As such the need for this combination to be successful for both companies is very high, and I think they do have a hit here.
The phone for voice calls (the reason for having a phone) is very good. I think it is better than my old RAZR and infinitely better than my old Treo. Reading email is good and the interface is sleek and easy to use. The only issue there is that the service we use for work doesn't allow me to open attachements, but they are still there. I imagine that Good will fix that in the near futurte. The operating system, Google's Android, is really cool. This is my first exposure to that OS. Obviously everyone is familiar with Apple's mobile OS (since I have an Ipod Touch), and this is consistent but different.
The big takeaway I have is that it is super fast. I mean, even maps, using my current location, so nothing that is pre-cached, is really fast. If this was baseball I would administer a drug test and expect to find steroids here it is so fast. But since it is a phone I doubt I'm going to find needle marks anywhere.
The thing I didn't realize is that the different elements can really drain the power. Which is why I have added a new blog to the list of blogs I'm tracking on the right side of this page. You'll see the Tech Broiler blog from Jason Perlow. He is starting a new section called Stupid Droid tricks to teach dummys like me how to efficiently use this device. I did have a problem. My battery drained in like 4 hours. I didn't realize that when every single service is running the machine is draining power. I read Stupid Droid Trick #1 and figured out how to easily turn off services that I don't need like disabling Wi-Fi when I'm not at home. Duh. I'll be looking for more stupid Droid tricks in the future.
Anyway, since I'm a federal employee, and we have to use the Networx contract, my department has had a relationship with Verizon and those are the only services and phones we are allowed to use. Sorry other companies, that is just how it is. So we are piloting the Droid and I really like it. I think this will really work for us. As a pilot tester it is my job to find out these little problems and identify solutions so that if we want to roll it out to the larger community they won't be forced to deal with headaches.
Monday, November 16, 2009
Quality Management
I have seen that many people often struggle with quality management on big development projects. The reason they often have a hard time in this area is not because they don't know how to manage for quality, or what quality is, rather the problem is that they have to define quality so early in the process.
Sorry for being quiet for so long. I have been traveling around the country teaching both state and Indian Tribe users as well as internal government people how to use my new application. I find it hard to write when I'm on the road like that. I need to be in my routine to get it. I feel like I'm now back in my routine, at least for a little while, I have some additional travel coming up, but nothing like the last few weeks.
Anyway, quality management. Remember, I'm approaching this from the perspective of a government PM, so most of the development work is performed by the contractor. When we award that contract we want to have the vendor be a part of the process defining quality. That is a terrible mistake because their version of quality may be different from your version of quality. And if you discover that difference after the contract has been awarded, guess what? You can have your version of quality, but we'll need a change order and a cost adjustment.
The reason so many good people fall down on quality management is because you have to define it to a fairly high level of granularity very early in the process. In fact, you have to define it and set it in stone before you even start working on requirements. What I mean is that you need to define quality in your Statement of Work, and you need to be very deliberate about it. Here is how I do it.
I develop a section of the SOW called "Performance Standards". This is a common section in a performance-based contract. Also remember that most of my contracts are Firm Fixed Price as well. That means that only 5 of the 6 dimensions of Project Management are in play for my projects, Quality, Schedule, Satisfaction, Risk and Scope. I don't have to worry about Cost in FFP. Additionally, I manage risk discretely. So I literally create a table with each area of service and make Quality, Schedule, Satisfaction and Scope the column headers. It looks like this:
Requirements Gathering Sessions
Quality - Stakeholder comments are implemented and functions need not be revisited.
Timeliness - RAP materials are available at least 2 days before the RGS. Meeting minutes are available no more than 2 days after. RGS are held on the day indicated in the project plan.
Satisfaction - Stakeholders are able to achieve consensus with the consistent process.
Scope - By the end of RGS, Activity Diagrams, Use Cases and a Requirements Baseline has been agreed to by consensus of the stakeholders.
I then have a Deliverables Table in the following section that describes the Quality, Timeliness, Satisfaction and Scope of each deliverable. I go through each of the service areas like this and objectively define them so that offerors are able to assemble a high-precision bid and everyone is on the same page in terms of expectations.
The reason this is difficult for some people is because you must define it so early in the process. Do not shy away from it though. You need to do it this way if you want to avoid problems later.
Sorry for being quiet for so long. I have been traveling around the country teaching both state and Indian Tribe users as well as internal government people how to use my new application. I find it hard to write when I'm on the road like that. I need to be in my routine to get it. I feel like I'm now back in my routine, at least for a little while, I have some additional travel coming up, but nothing like the last few weeks.
Anyway, quality management. Remember, I'm approaching this from the perspective of a government PM, so most of the development work is performed by the contractor. When we award that contract we want to have the vendor be a part of the process defining quality. That is a terrible mistake because their version of quality may be different from your version of quality. And if you discover that difference after the contract has been awarded, guess what? You can have your version of quality, but we'll need a change order and a cost adjustment.
The reason so many good people fall down on quality management is because you have to define it to a fairly high level of granularity very early in the process. In fact, you have to define it and set it in stone before you even start working on requirements. What I mean is that you need to define quality in your Statement of Work, and you need to be very deliberate about it. Here is how I do it.
I develop a section of the SOW called "Performance Standards". This is a common section in a performance-based contract. Also remember that most of my contracts are Firm Fixed Price as well. That means that only 5 of the 6 dimensions of Project Management are in play for my projects, Quality, Schedule, Satisfaction, Risk and Scope. I don't have to worry about Cost in FFP. Additionally, I manage risk discretely. So I literally create a table with each area of service and make Quality, Schedule, Satisfaction and Scope the column headers. It looks like this:
Requirements Gathering Sessions
Quality - Stakeholder comments are implemented and functions need not be revisited.
Timeliness - RAP materials are available at least 2 days before the RGS. Meeting minutes are available no more than 2 days after. RGS are held on the day indicated in the project plan.
Satisfaction - Stakeholders are able to achieve consensus with the consistent process.
Scope - By the end of RGS, Activity Diagrams, Use Cases and a Requirements Baseline has been agreed to by consensus of the stakeholders.
I then have a Deliverables Table in the following section that describes the Quality, Timeliness, Satisfaction and Scope of each deliverable. I go through each of the service areas like this and objectively define them so that offerors are able to assemble a high-precision bid and everyone is on the same page in terms of expectations.
The reason this is difficult for some people is because you must define it so early in the process. Do not shy away from it though. You need to do it this way if you want to avoid problems later.
Subscribe to:
Comments (Atom)